package.xml 2.0 dilemma

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.