Re: package.xml 2.0 dilemma

Hi Greg and all, I assume allmost all v2 package xml are just generated. Sorry for real writers :) , just tell us. So any change could "only" need a re-generation... means +1 for me, it's just the time. If I get you right, Greg, you want to stick to XML-Schema ? Do you have some .xsd material ? à+ -- bertrand Gugger http://toggg.com/ Greg Beaver wrote: > Hi all, > > As Alan has mentioned in > > http://pear.php.net/bugs/4457 (*) > > package.xml 2.0 currently has a specific tag ordering. I made this > choice because XSchema has only three kinds of ordering indicators, > sequence, choice and all. sequence allows very fine-grained control > over elements, choice says "any of these elements can occur here" and > all says "any of these elements can occur in any order". > > The problem with the all indicator is that there can only be 1 of a > particular tag. In other words, this hypothetical xml: > > <package> > <name/> > <summary/> > <lead/> > <lead/> > </package> > > would be invalid because it has 2 <lead/> tags. > > However, there is a way around this. Tags can have child sequences, > which means if I put back in the old <maintainers> tag like so > > <package> > <name/> > <summary/> > <maintainers> > <lead/> > <lead/> > </maintainers> > </package> > > Then we can have more flexible tag ordering in package.xml. > > The problem with this is that suddenly, older package.xml 2.0-based > releases will become invalid. > > My question to you all is: is it worth it to slightly re-organize the > package.xml at the expense of breaking BC. The changes would be > > 1) all maintainers would be inside <maintainers> > 2) channel/uri would be inside new tag <origin> > 3) usesroles/usestask would be inside <uses> > 4) srcpackage/srcuri would be inside new tag <src> > > The first two will break every existing release. > > I'm inclined to think that this is not worth the trouble, but want to > make sure everyone is heard before making a decision. Benefits of the > change would be: > > 1) slightly less code in PEAR_PackageFile_v2 > 2) smaller validation code in PEAR_PackageFile_v2_Validator > 3) flexibility in element ordering in package.xml version 2.0 > > Disadvantages would be > > 1) every release using package.xml 2.0 up to now is suddenly invalid > 2) debugging by eye becomes more difficult due to the possibility to > put tags anywhere in the file > > Opinions? > > Greg > > (*) I will be relaxing the ordering of <dir>/<file> inside <contents>, > that is no problem. >