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

[Robert Lemke]

Hi David,

Am 17.03.2008 um 19:46 schrieb David Bruehlmeier:

> I have now created a RelaxNG schema trying to incorporate your  
> feedback
> as well as the discussions and drafts on forge [1].

Thank you! I also prefer RelaxNG - it's just easier to handle.

> The schema:
> http://www.bruehlmeier.com/fileadmin/flow3/Package.rng
>
> And an example XML:
> http://www.bruehlmeier.com/fileadmin/flow3/Package.xml
>
> Some comments:
>
> 1. I have seen on forge that the name PackageInfo.xml doesn't seem  
> to be
> untouchable. What about just naming it Package.xml?

Nothing in FLOW3 is untouchable ;-)

Okay, we can rename it. Can you create a ticket for that and assign it  
to me?

> 2. The namespace would be xmlns="http://typo3.org/ns/2008/flow3/package 
> "

perfect.

> 3. The root element would be just <package>

yes.

> 4. I would refrain from having a version "history" in this file, as
> suggested in one of the files on forge (multiple <version> elements).
> IMO, it is up to the Repository to version the packages and it should
> not be done within this single file.

I agree.

> 5. The schema is less permissive now, most of the elements are  
> required.
>
> 6. Instead of introducing <author>, <maintainer> et al, why not  
> "borrow"
> the concept from OASIS xPIL [2] and introduce a <party> element with
> zero or more <person> and/or <company> elements? Each party can have a
> "role" attribute, like "LeadDeveloper", "Maintainer", "Sponsor",  
> etc. Of
> course, we don't need full-fledged xPIL elements, but why re-invent  
> the
> wheel? Something like "roles" was also suggested by Ingo Renner for  
> 4.x
> on forge.

ok.

> 7. Each constraint (depends/conflicts/suggests) can contain three
> different elements:
> * <package>
> * <component> (was suggested by Robert on forge)

That will be quite hard to check because the class in question needs  
to be
loaded in order to check its version.

Let's drop it for now and introduce it again in case we really really  
need
it.

> * <system>
>
> 8. The <system> element has a "type" attribute and only allows for
> parameters which can actually be checked in PHP:
> * PHP: Checked with phpversion()
> * PHPExtension: Checked with php_uname()
> * Memory: Checked with memory_get_usage()
>
> 9. All constraints can have an (optional) minVersion and/or an
> (optional) maxVersion. The versions are defined to be inclusive, so
> checking should be easy using version_compare(). No operator signs are
> needed as suggested on forge.
>
> 10. Please use ISO8601 [3] only when representing dates and or  
> times. It
> is a built-in type in both XSD and RNG and will never cause trouble. I
> suggest the full representation including time zone, such as:
> 2008-04-22T17:23:09Z

Yes, that is, by the way, the standard we agreed on for FLOW3 in  
general.
It is already used for generating file names for the file cache for  
example.

> 11. As for the question XSD or RNG: I get the feeling that RNG seems  
> to
> be the choice that is better accepted for FLOW3. In some circumstances
> (like for the FLOW3 Development Environment, which is written in  
> Java),
> it would still be nice to have an XSD. What about if we declare the  
> RNG
> schema to be normative, but still offer a non-normative XSD which can
> easily be generated from RNG using the Trang Converter [4]. It would
> look like this:
>
> http://www.bruehlmeier.com/fileadmin/flow3/Package.xsd

Great!

Thank you for taking care,
robert
-- 
http://typo3.org/gimmefive
http://buzz.typo3.org/people/robert-lemke/