[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK-APPS: RE: XML catalog resolution problems
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC