Re: package.xml DTD 1.1 avaible

From: Date: Thu, 04 Sep 2003 10:33:31 +0000
Subject: Re: package.xml DTD 1.1 avaible
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-21053@lists.php.net to get a copy of this message
On Thursday, September 4, 2003 10:43, Stefan Neufeind wrote: > On 4 Sep 2003 at 1:10, Tomas V.V.Cox wrote: >> On Thursday, September 4, 2003 0:42, Stefan Neufeind wrote: >> >> > On 3 Sep 2003 at 14:22, Tomas V.V.Cox wrote: >> >> >> I've done an big update/fix/complete of the current DTD 1.0. The >> >> main purpose of it, is to support all the new features added in the >> >> recent months and to be more strict on the pacakge.xml format. >> >> >> >> Almost none (if any) pacakge.xml file under the PEAR CVS conforms >> >> the new DTD (mostly because of the new required element order). >> >> Please review and test it (you can use the xmllint --dtdvalid >> >> command shipped with libxml2 or my DTD class), because I'd like to >> >> add DTD validation into "pear package-validate" and perhaps in the >> >> future to comply with the DTD, could become a requirement (both at >> >> the pear-cmd and the web). >> >> >> >> You can find the new dtd at: >> >> >> >> http://pear.php.net/dtd/package.1.1.dtd >> >> >> >> (is not yet a public url) >> >> > And it doesn't even appear to be "public" for us :-) Could you check >> > the url again, please? >> >> The correct url is actually: >> >> http://pear.php.net/dtd/package-1.1.dtd > Tomas, > testing your dtd against a package.xml of I got some problems > First some elements need to be re-ordered - no big deal. But: You know that the XML spec forces the order of elements (deterministic model). So if you declare in the DTD: <!ELEMENT foo (a,b,c)> The elements have to appear exactly as <foo><a/><b/><c/></foo>, contrary to SGML where the order wasn't important. Of course you can emulate unordered lists but it's a little bit tricky. <!ELEMENT foo ((a,b,c)|(a,c,b)|(b,a,c)|(b,c,a)|(c,a,b)|(c,b,a))> I guess this could be normalized, perhaps Jesus could enlight us about how :-). A common solution to this problem is just doing: <!ELEMENT foo (a|b|c)+> Which is wrong in our case because repetitions of one element are allowed. Anyways, I really preffer to be strict with the format, this will save a lot of checking code in the PEAR libs, plus all package.xml will look very similar. > 1) Why may the provides-container exist but isn't demanded? What use > might a package have that doesn't provide anything? Try: $ pear package Foo/package.xml $ tar xvfz Foo-1.1.tgz $ less package.xml You'll see that the original package.xml and the one shipped within the package are slighty different. There you'll see the "provides", the md5sums for files, etc. The DTD-1.1 was build for being able to validate both original and processed package.xml. > 2) Every changelog-item is also of type "release". But do you really > think a complete changelog should include the "filelist" for every > release? With some packages this might extremely increase the size of > the package.xml. Is it useful for anything? Nop, the changelog tag is just that, a lazy way for storing the list of changes (only the list). In the future the great think will be that at "pear package" time, the pear-cmd retrieves from the web the list of changes and create a real stand alone Changelog file for being shippied with the release. > All other things seem to work fine. Will update the package.xml-files > in CVS according to the dtd as soon as the above mentioned points can > be cleared. Prior to this step, we should provide a tool for the developers to DTD check their package.xml files. That will happen when finish the commit of the DTD package or well, if you do have Linux and the xmllint cmd you could start now. Of course if we all agree with the changes to the DTD :-) -- Tomas V.V.Cox mailto:cox@idecnet.com

« previous php.pear.dev (#21053) next »