Re: Relaxing package.xml v2 XSD

Hi Brett, Brett Bieber wrote: > Hey Philippe, > > On Thu, May 1, 2008 at 11:09 AM, Philippe Jausions > <Philippe.Jausions@11abacus.com> wrote: >> Hi, >> >> The current XSD for package.xml version 2 >> (http://pear.php.net/dtd/package-2.0.xsd), doesn't allow simple nested >> folder structures without files in them. [...snip...] > And a couple solutions...? > 1. relax the schema > 2. validate package.xml and reject releases that do not validate..? > > Given that we have so many releases out in the wild that do not > validate, I think our efforts should focus on relaxing the schema. > > The numbers should make it obvious that strict validation does not > matter to the current PEAR installer. But, this will change with > Pyrus, as strict validation for package files is checked using > DOMDocument::schemaValidate A lot of copy/paste is done when creating a package.xml file, so depending on whether the original is correct, so most likely will be the copy. I think checking the validity of the package.xml file at packaging time is the best time to do it, i.e. "pear package-validate package.xml" should inform the developer of all the issues and should refuse packaging the package if the schema validation fails. It currently partially catches gross errors, such as no <contents> element. FYI: I never checked the validity of the package.xml against its XSD before, and only recently noticed issues when I started to use Eclipse and its XML editor, which BTW are both great integrated tools. >> Would it be huge deal breaker to anyone to allow <dir> to not contain >> files, but just sub-<dir>? > > I don't have any major objections to this... but I think it may be > hard to figure out a way to require a file at the end of it - to > prevent a package that just contains directories and no files. Is this > a concern we should be worried about? The only concern that may exist is with a packaging tool that would encounter a symlink referencing the parent folder while trying to automatically generate a package.xml at the same time. Anyway, that problem already exists currently, so relaxing the XSD wouldn't change that issue. > But there are other issues that I think need to be addressed. > Specifically, the ordering of elements should be a little more > flexible directly under the package element. Here there is a very long > sequence requiring every element be present. While I'm fine with > requiring the presence of the elements, I think it should allow > flexible ordering. > > I believe the best way is to change from sequence to choice - and > enumerate all the possible sequences. This would allow us to still > require that all elements be present, but allow more flexible > ordering. Although this would give us a very large schema file, and > would make it more difficult to make modifications to the file in the > future. This is fine too, but this is just for convenience, and not something that fixes an impossibility to begin with. > I think we should work up some patches for the package schema, and run > some tests to see what it looks like. As for your changes Philippe, I > think that sounds fine. I see no reason to not allow directories with > only subdirectories as the content, as long as there's a file at the > end of it. Yes, agreed, I don't see the point of nested folders without anything at the end anyway ;-) That restriction on nested folders and files is really a PITA, at least for me. Are there other dev out there having issues with, or are aware thereof, the current XSD 2.0? So, what's the next step? RFC? -Philippe