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

[Robert Lemke]

Hi David,

Am 17.03.2008 um 09:21 schrieb David Bruehlmeier:

> I would like to suggest an XML schema for the PackageInfo.xsd file. It
> would be very helpful for me to implement the XML import/export for  
> the
> FLOW3 Development Environment, but I think it would generally be a  
> good
> idea to agree on a schema for this file.

good that you pick up on that. As you probably have seen, there's  
already
exists a ticket for that topic (http://forge.typo3.org/issues/show/14),
maybe you add your information to it?

> Please have a look at the schema and give me feedback:
> http://www.bruehlmeier.com/fileadmin/flow3/PackageInfo.xsd
>
> The schema is quite permissive. The only required element is the  
> package
> key. Most types are just xs:strings.

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

I suggest that we at least require this information to be defined:

   - key
   - title
   - version
   - state
   - at least 1 author

> The schema introduces the following changes. What do you think?
>
> 1. Introduce the namespace
> xmlns="http://typo3.org/ns/2008/flow3/PackageInfo"

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

> 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?

> 3. Rename the element "packageKey" to "key" (DRY, it's already not
> "packageVersion" but "version", etc.)

okay.

> 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"?

> 4. Allow more than one category to be assigned (That's one thing that
> always bugged me about the categorization in TYPO3, because sometimes
> more than one category fit. This way, it's more like "tagging" the
> package with all the categories that apply).

yes.

> 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.

This information might be added / overidden automatically by the package
repository.

> 6. The attribute for defining a minimal version of a constraining
> package currently is "atLeastVersion". I think there should also be a
> way to define the maximum version. Therefore, I suggest renaming these
> attributes to "minVersion" and "maxVersion".

yes

> 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.

>

Cheers,

robert
-- 
http://typo3.org/gimmefive
http://buzz.typo3.org/people/robert-lemke/