OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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,



Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/