Re: package.xml 2.0 dilemma

Agh, the pain of XML tools ;) out of interest where is the XSchema code? I"m not sure how many packages are using package2.xml yet. I'd like the format to be a little more flexible, and what you describe sounds clearer, so if you are going to break it, the sooner the better.. It would also be usefull if we could create packages (eg. generate package.xml(v1) that could be installed by the older pear.. - but I guess that's quite a bit of work. Regards Alan On Wed, 2005-06-01 at 21:44 -0400, 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. >