Re: package.xml 2.0 dilemma

On 6/1/05, Greg Beaver <cellog@php.net> 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". > Ok, I'm still not sure what these choices mean. How is "sequence" fine-grained and how is this bettter than the others? > 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. > Well...it seems you have to sequence your XML to have multiples of a tag. I suppose this makes some sense as otherwise you basically have an assoc array. Still, though, it doesn't make much sense to me to force sequencing for most of the tags as they're pretty much just an assoc array. IMHO as long as the sequence doesn't actually mean anything (i.e. you could change the sequence and it wouldn't change the meaning) then the tags shouldn't be forced to be in a certain sequence. It would make perfect sense to me to take out the sequencing and have child sequences to allow for multiples of the same tag. I also think this would be easier to use. > 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 > I see all of those as great davantages. In addition package.xml 2.0 won't be forcing developers to keep tags in an arbitrary sequence. > Disadvantages would be > > 1) every release using package.xml 2.0 up to now is suddenly invalid Oh well. This is pretty much a non-issue as PEAR 1.4 is still alpha. If people have been relying on it they can always change it. I do have a question, though. Will older releases with both package.xml and paxkage2.xml break or will it install fine with the package.xml even though the package2.xml won't validate? > 2) debugging by eye becomes more difficult due to the possibility to put > tags anywhere in the file > This doesn't seem like too bad of a thing to me. Validation will still say "missing <blah> tag" or "<blah> tag not allowed in <foo> tag" (I assume). -- Justin Patrin