Re: DOCBOOK-APPS: RE: XML catalog resolution problems

[Paul Grosso <pgrosso at arbortext dot com>]

At 14:08 2002 10 30 -0500, Daniel Veillard wrote:
>On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote:
>> But I will try again to give you a more technical explanation.
>> 
>> The use of systemId in the XML Catalog is expressly to model 
>> production [75], ExternalID, of the XML spec.  I think it is 
>> good architecture to model what the catalog does on what the 
>> XML spec is doing.
>
>  The XML spec in 4.2.2 explicitely state that in production 75 
>the System ID is an URI-Reference and link to RFC 2396.

RFC 2396 <ftp://ftp.ietf.org/rfc/rfc2396.txt> defines:

  URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

The XML spec says a system identifier cannot include a fragment identifier.

So the XML system identifier matches [ absoluteURI | relativeURI ]
in RFC 2396 (for which there is no single name given in 2396)
whereas the URIs matched by the uri catalog entry match the full
URI-reference production above.

>  The XInclude spec does the same for the href attribute.
>  There is no XML Base, so both references uses the same base
>and anybody with some common sense would expect the two references
>to get to the same resource.

An XInclude href consists of a URI.  An XML doctype declaration's
ExternalID consists of both a public identifier and a system identifier.
They sound very different to me, and it makes perfect sense for two
such different references to be able to resolve to different resources.


At 13:54 2002 10 30 -0500, Daniel Veillard wrote:
>On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote:
>> Many XML processors provide an option to "compile" the external 
>> subset for certain optimized uses, so the system identifier (in 
>> the doctype line) might really resolve to some compiled form, 
>> but the URI in the xinclude element would want to resolve to 
>> the uncompiled form.
>
>  haha, that's the underlying implementation breakage which is the
>cause of all this !!! This means you have internal APIs which doesn't
>allow you do make the differentiation, this does not justify pushing
>that differentiation at the description level, sorry :-(

I fail to see what is broken.  I don't understand your point about
internal APIs.  Users want to be able to point to different resources
in the case of system ids and URIs.  

>> Or I might know that my application ideally supports a slightly
>> different version of the DTD, so I want to map the system id
>> into some other file--maybe one on my local system, or maybe
>> off to the latest test version of the DTD on sourceforge--but
>> the version I want to include as text in my document should be
>> the official current version of the DTD.
>
>  Hum, and you expect this to not lead to huge confusion ????

Absolutely not.  It is a user requirement to be able to do this,
and it is a reasonable architectural requirement to support.

I have users telling me they want to do this, and it makes perfect
sense to me what they want to be able to do.

>As a result all users for all XML tool chain using catalogs
>suddenly MUST duplicate ALL their SYSTEM entries into URI entries
>just to avoid this ? This is broken !

You don't have to duplicate all system entries because you
don't need URI entries unless you want to point to a DTD 
(which is what system ids usually point to) as something 
other than a DTD which is a rare occurrence.

I very much disagree with your "broken" assertion, Daniel.
You asked for an explanation, and I gave it to you, and
you respond by telling me my users' requirements are
"broken."  And you think this justifies your insisting
on keeping your implementation non-compliant with an OASIS
specification!

paul