[TYPO3-50-general] XML schema for PackageInfo.xsd

[David Bruehlmeier]

Hi Robert,

> Hmm, why did you make it so permissive? Do you think that making it more
> restrictive would cause problems?

I wasn't sure what your policy on that was.

> 
> I suggest that we at least require this information to be defined:
> 
>   - key
>   - title
>   - version
>   - state
>   - at least 1 author

Yes, the new version is much less permissive now.

> 
> AFAIR we agreed on having only lowercase URIs, so I suggest to use
> http://typo3.org/ns/2008/flow3/packageinfo instead.

I changed that.

> 
>> 2. Introduce a "version" attribute in the root element "packageInfo"
> 
> okay, but wouldn't it make sense to transform the "key" to a packageInfo
> attribute as well?

It's the eternal question: attribute or element? AFAIK the rule of thumb 
is: "If it's meta-data, put it in attributes, otherwise in elements". 
Since we are in the domain "package", the key of the package seems like 
real data and not just meta-data to me. That's why I chose to make it an 
element. But I guess in the end, it's just a matter of personal preference.

> 
>> 3. Introduce a new element "state" after "version" which is defined by
>> an enmueration to be "Experimental", "Alpha", "Beta", "Stable" or 
>> "Obsolete"
> 
> How about "Development", "Alpha", "Beta", "ReleaseCandidate" (or "RC"), 
> "Final"
> and "Obsolete"?

I changed that.

> 
>> 5. Allow more than one author and "normalize" the author element (see
>> example below)
> 
> yes.
> 
> I could imagine that we add another tag: "maintainer"
> 
> <maintainer>
>     <name>John Smith</name>
>     <email>john at smith.com</email>
>     <username>john</username>
> </maintainer>
> 
> There may be more than one maintainer.
> 

I propose to use a generaly <party> element with <person> and 
<organisation> elements with respective "role" attributes. See my other 
post.

> 
>> 7. Split the contraints into FLOW3 packages and system constaints such
>> as available programming languages, operating system, memory, etc.
> 
> yes, we'll have to see how that will be checked though.

The new proposal only contains attributes which can be checked. It's 
less "general" that way, but I feel it makes more sense.

Best regards,
Dave