[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Public Indentifier
On Wed, Sep 05, 2001 at 10:31:18AM -0700, Lauren Wood wrote: > We only finished the spec last month! Can you give us (and the other software > vendors) at least some time to support it? Actually, this thread is also helping > to tell people that the specification exists, so hopefully more people will think > about using it. Hum, I don't see libxml listed, though I have implemented it fully and it's in libxml2-2.4.3 release. > And yes, the first supporters are likely to be SGML people who see > the need, but I believe that others will also see the need eventually and be glad > a specification is there. I also didn't got a valid answer why you decided that system identifier resolution in the DOCTYPE and elsewhere in the document had to be done in a different way and using a different syntax in the Catalogs ! As an implementor, this is bad, I have to double the APIs. As someone who tries to standardize the use of XML Catalogs for Linux as part of the LSB this makes my life harder too because basically I need to tell people to duplicate all their SYSTEM entries as URI entries in the catalogs produced. So not only is this a really bizare deviation on how an URI reference is supposed to be handled in the general case, it nearly doubles the number of APIs nedded to handle XML Catalogs in toolkits, and it also increase seriously the size of the Catalogs we will have to deploy. All this for no other reason given that "we decided we want this". I think it breaks my toolkit API forcing me to do some convoluted handling of URI references (i.e. a really critical path), offers 0 advantage (if you rely on URI references to resolve differently just because they happen to be processed as part of a DOCTYPE you will get troubles sooner or later), and actually may harm interoperability because I would very well understand why in the absence of some context toolkit A and toolkit B may diverge, one applying the algorithm from 7.1 and the other applying the algorithm from 7.2 . Making the resolution algorithm dependant on the URI-Reference location within the document is a mistake. This may be the case that you are doing this to preserve SGML Toolkits catalogs existing implementations, maybe this is not the best way to get your spec deployed widely (and I still consider the possibility of discarding the algorithm from 7.2 applying only the one from 7.1 in my implementation to avoid that silly duplication, though I currently tried to implement the 06 Aug 2001 spec as-is). Otherwise the spec is nice, was relatively easy to implement, and I hope will fill a real need as we are deploying widely DocBook and related XML tools in the Linux distributions. Your first large scale users are likely to be Linux distributions, probably faster than SGML vendors, yours, Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@r... | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|