DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | What is the reason for requiring EntityResolver to always return | fully resolved system IDs in the first place? Why did Norm lose | the argument? I'm not sure I can answer this question in a completely objective way. I think the answer boils down to this: the SAX folks made some decisions about their API in the V1 days and unfortunately no one noticed the places where the decisions they made were going to impact proper functioning of a resolver. Because SAX is very popular, and perhaps because they disagree that their API is broken, they are unwilling to change the public API. So if you're going to use SAX, you're stuck with a broken API. I'm hoping to move away from SAX and start using the Xerces Native Interface myself. XNI exposes all of the events that occur and will allow me to do some quite nice things (like profile at the parser level, normalize namespace prefixes, implement XInclude before DTD validation, etc.). Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The common excuse of those who http://www.oasis-open.org/docbook/ | bring misfortune on others is that Chair, DocBook Technical Committee | they desire their | good.--Vauvenargues -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE+OnNROyltUcwYWjsRAqugAJ9BR3af4TrHrgnZxbjSnl4+PhdHIACeMbDQ AFPv47FNp+MT/imRN/svs0A= =9iUM -END PGP SIGNATURE-
RE: DOCBOOK-APPS: RE: XML catalog resolution problems
-Original Message- From: Bob Stayton [mailto:[EMAIL PROTECTED]] Sent: Friday, November 08, 2002 7:13 PM To: Jeanson Mauritz; Norman Walsh Cc: [EMAIL PROTECTED] Subject: Re: DOCBOOK-APPS: RE: XML catalog resolution problems I had some further correspondence with Norm about this problem. It turns out that relative system ids can't be resolved by the Java resolver classes because they never even see them in their original form. He explained that the SAX API resolves a relative system id such as docbookx.dtd as relative to the document's directory. The SAX API changed docbookx.dtd to file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd in the parsing stage. That's why the resolver reports: resolveSystem(file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd) instead of: resolveSystem(docbookx.dtd) He says there is no hook for the resolver classes to get the original docbookx.dtd string for the resolver to look up in the catalog. He says he argued against this behavior at the time, but lost. I tried faking an absolute path, with a system id such as /docbookx.dtd. But I found that my XML catalog needed to have three catalog entries with three different systemIds if I wanted to use different processors: systemId=/docbookx.dtd (xsltproc) systemId=file:/docbookx.dtd (saxon) systemId=file:///docbookx.dtd(xalan) Ugh! Better to use a fake URI such as http://docbookx.dtd; in your files and catalog since that shouldn't be messed with by the parsers. The explanation makes sense even though it is awkward having to fake the system IDs. What is the reason for requiring EntityResolver to always return fully resolved system IDs in the first place? Why did Norm lose the argument? /Mauritz
DOCBOOK-APPS: RE: XML catalog resolution problems
-Original Message- From: Norman Walsh [mailto:ndw;nwalsh.com] Sent: Friday, October 25, 2002 7:06 PM To: Jeanson Mauritz Cc: [EMAIL PROTECTED] Subject: Re: XML catalog resolution problems -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | This is the current score: | | A. Resolution of system IDs: does not work at all. | | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, | 2. use uri instead of system in the catalog file, | 3. prepend the xml file name with file: on the command line, and | 4. use a system ID with full path to the DTD (or a public ID). That's very odd. Try turning up the verbosity of the resolver. A setting of 4 or more should produce a complete dump of everything it tried to do. Here is a test of system IDs that fails. In this example I use the catalog only for the DTD, and not for the stylesheet. Doctype declaration in the XML file: !DOCTYPE article SYSTEM docbookx.dtd Catalog file: catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog system systemId=docbookx.dtd uri=file:///c:/doctypes/docbook/xml/docbookx.dtd/ catalog Below is a complete dump from my attempt to resolve the system ID. (I use Swedish Win2K: Det går inte att hitta filen means the file cannot be found). What goes wrong here? For some reason it works perfectly if I use a public ID instead, like this: !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN docbookx.dtd and catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog public publicId=-//OASIS//DTD DocBook XML V4.1.2//EN uri=file:///c:/doctypes/docbook/xml/docbookx.dtd catalog Regards, Mauritz J Dump for System ID resolution = C:/jdk1.3.1/bin/java -classpath \ .;c:/xmltest/catalogs/resolver-1.1/resolver.jar;c:/Java/saxon/saxon.jar \ com.icl.saxon.StyleSheet \ -r org.apache.xml.resolver.tools.CatalogResolver \ -x org.apache.xml.resolver.tools.ResolvingXMLReader \ -y org.apache.xml.resolver.tools.ResolvingXMLReader \ -o kprof.html kprof.xml c:/doctypes/docbook/xsl/html/docbook.xsl Parse catalog: catalog.xml Loading catalog: catalog.xml Default BASE: file:/c:/XMLtest/catalogs/test/Saxon/catalog.xml system: docbookx.dtd file:///c:/doctypes/docbook/xml/docbookx.dtd SYSTEM: docbookx.dtd file:/c:/doctypes/docbook/xml/docbookx.dtd resolveURI(../VERSION) Resolved URI: ../VERSION file:/c:/doctypes/docbook/xsl/VERSION resolveURI(param.xsl) Resolved URI: param.xsl file:/c:/doctypes/docbook/xsl/html/param.xsl resolveURI(../lib/lib.xsl) Resolved URI: ../lib/lib.xsl file:/c:/doctypes/docbook/xsl/lib/lib.xsl resolveURI(../common/l10n.xsl) Resolved URI: ../common/l10n.xsl file:/c:/doctypes/docbook/xsl/common/l10n.xsl resolveURI(../common/common.xsl) Resolved URI: ../common/common.xsl file:/c:/doctypes/docbook/xsl/common/common.xsl resolveURI(../common/labels.xsl) Resolved URI: ../common/labels.xsl file:/c:/doctypes/docbook/xsl/common/labels.xsl resolveURI(../common/titles.xsl) Resolved URI: ../common/titles.xsl file:/c:/doctypes/docbook/xsl/common/titles.xsl resolveURI(../common/subtitles.xsl) Resolved URI: ../common/subtitles.xsl file:/c:/doctypes/docbook/xsl/common/subtitles.xsl resolveURI(../common/gentext.xsl) Resolved URI: ../common/gentext.xsl file:/c:/doctypes/docbook/xsl/common/gentext.xsl resolveURI(../common/targets.xsl) Resolved URI: ../common/targets.xsl file:/c:/doctypes/docbook/xsl/common/targets.xsl resolveURI(autotoc.xsl) Resolved URI: autotoc.xsl file:/c:/doctypes/docbook/xsl/html/autotoc.xsl resolveURI(autoidx.xsl) Resolved URI: autoidx.xsl file:/c:/doctypes/docbook/xsl/html/autoidx.xsl resolveURI(lists.xsl) Resolved URI: lists.xsl file:/c:/doctypes/docbook/xsl/html/lists.xsl resolveURI(callout.xsl) Resolved URI: callout.xsl file:/c:/doctypes/docbook/xsl/html/callout.xsl resolveURI(verbatim.xsl) Resolved URI: verbatim.xsl file:/c:/doctypes/docbook/xsl/html/verbatim.xsl resolveURI(graphics.xsl) Resolved URI: graphics.xsl file:/c:/doctypes/docbook/xsl/html/graphics.xsl resolveURI(xref.xsl) Resolved URI: xref.xsl file:/c:/doctypes/docbook/xsl/html/xref.xsl resolveURI(formal.xsl) Resolved URI: formal.xsl file:/c:/doctypes/docbook/xsl/html/formal.xsl resolveURI(table.xsl) Resolved URI: table.xsl file:/c:/doctypes/docbook/xsl/html/table.xsl resolveURI(../common/table.xsl) Resolved URI: ../common/table.xsl file:/c:/doctypes/docbook/xsl/common/table.xsl resolveURI(sections.xsl) Resolved URI: sections.xsl file:/c:/doctypes/docbook/xsl/html/sections.xsl resolveURI(inline.xsl) Resolved URI: inline.xsl file:/c:/doctypes/docbook/xsl/html/inline.xsl resolveURI(footnote.xsl) Resolved URI: footnote.xsl file:/c:/doctypes/docbook/xsl/html/footnote.xsl resolveURI(html.xsl)
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
I had some further correspondence with Norm about this problem. It turns out that relative system ids can't be resolved by the Java resolver classes because they never even see them in their original form. He explained that the SAX API resolves a relative system id such as docbookx.dtd as relative to the document's directory. The SAX API changed docbookx.dtd to file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd in the parsing stage. That's why the resolver reports: resolveSystem(file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd) instead of: resolveSystem(docbookx.dtd) He says there is no hook for the resolver classes to get the original docbookx.dtd string for the resolver to look up in the catalog. He says he argued against this behavior at the time, but lost. I tried faking an absolute path, with a system id such as /docbookx.dtd. But I found that my XML catalog needed to have three catalog entries with three different systemIds if I wanted to use different processors: systemId=/docbookx.dtd (xsltproc) systemId=file:/docbookx.dtd (saxon) systemId=file:///docbookx.dtd(xalan) Ugh! Better to use a fake URI such as http://docbookx.dtd; in your files and catalog since that shouldn't be messed with by the parsers. Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED] On Fri, Nov 08, 2002 at 02:59:40PM +0100, Jeanson Mauritz wrote: -Original Message- From: Norman Walsh [mailto:ndw;nwalsh.com] Sent: Friday, October 25, 2002 7:06 PM To: Jeanson Mauritz Cc: [EMAIL PROTECTED] Subject: Re: XML catalog resolution problems -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | This is the current score: | | A. Resolution of system IDs: does not work at all. | | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, | 2. use uri instead of system in the catalog file, | 3. prepend the xml file name with file: on the command line, and | 4. use a system ID with full path to the DTD (or a public ID). That's very odd. Try turning up the verbosity of the resolver. A setting of 4 or more should produce a complete dump of everything it tried to do. Here is a test of system IDs that fails. In this example I use the catalog only for the DTD, and not for the stylesheet. Doctype declaration in the XML file: !DOCTYPE article SYSTEM docbookx.dtd Catalog file: catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog system systemId=docbookx.dtd uri=file:///c:/doctypes/docbook/xml/docbookx.dtd/ catalog Below is a complete dump from my attempt to resolve the system ID. (I use Swedish Win2K: Det ger inte att hitta filen means the file cannot be found). What goes wrong here? For some reason it works perfectly if I use a public ID instead, like this: !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.1.2//EN docbookx.dtd and catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog public publicId=-//OASIS//DTD DocBook XML V4.1.2//EN uri=file:///c:/doctypes/docbook/xml/docbookx.dtd catalog Regards, Mauritz J Dump for System ID resolution = C:/jdk1.3.1/bin/java -classpath \ .;c:/xmltest/catalogs/resolver-1.1/resolver.jar;c:/Java/saxon/saxon.jar \ com.icl.saxon.StyleSheet \ -r org.apache.xml.resolver.tools.CatalogResolver \ -x org.apache.xml.resolver.tools.ResolvingXMLReader \ -y org.apache.xml.resolver.tools.ResolvingXMLReader \ -o kprof.html kprof.xml c:/doctypes/docbook/xsl/html/docbook.xsl Parse catalog: catalog.xml Loading catalog: catalog.xml Default BASE: file:/c:/XMLtest/catalogs/test/Saxon/catalog.xml system: docbookx.dtd file:///c:/doctypes/docbook/xml/docbookx.dtd SYSTEM: docbookx.dtd file:/c:/doctypes/docbook/xml/docbookx.dtd resolveURI(../VERSION) Resolved URI: ../VERSION file:/c:/doctypes/docbook/xsl/VERSION resolveURI(param.xsl) Resolved URI: param.xsl file:/c:/doctypes/docbook/xsl/html/param.xsl resolveURI(../lib/lib.xsl) Resolved URI: ../lib/lib.xsl file:/c:/doctypes/docbook/xsl/lib/lib.xsl resolveURI(../common/l10n.xsl) Resolved URI: ../common/l10n.xsl file:/c:/doctypes/docbook/xsl/common/l10n.xsl resolveURI(../common/common.xsl) Resolved URI: ../common/common.xsl file:/c:/doctypes/docbook/xsl/common/common.xsl resolveURI(../common/labels.xsl) Resolved URI: ../common/labels.xsl file:/c:/doctypes/docbook/xsl/common/labels.xsl resolveURI(../common/titles.xsl) Resolved URI: ../common/titles.xsl file:/c:/doctypes/docbook/xsl/common/titles.xsl
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
At 10:12 2002 11 08 -0800, Bob Stayton wrote: I had some further correspondence with Norm about this problem. It turns out that relative system ids can't be resolved by the Java resolver classes because they never even see them in their original form. He explained that the SAX API resolves a relative system id such as docbookx.dtd as relative to the document's directory. The SAX API changed docbookx.dtd to file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd in the parsing stage. That's why the resolver reports: resolveSystem(file:/c:/XMLtest/catalogs/test/Saxon/docbookx.dtd) instead of: resolveSystem(docbookx.dtd) He says there is no hook for the resolver classes to get the original docbookx.dtd string for the resolver to look up in the catalog. He says he argued against this behavior at the time, but lost. To put a sharper point on it, SAX is broken. When Norm tried to explain why and have it fixed, whoever all gets to make the decision decided to leave SAX broken. It's a real shame. There are tools (that don't use SAX to resolve external entities) that do work correctly. paul
DOCBOOK-APPS: Re: XML catalog resolution problems
On Wed, Oct 30, 2002 at 12:31:32PM -0800, Norman Walsh wrote: I am, to be frank, disappointed and frustrated that you've blown a great big hole in a smooth operation of XML Catalogs. The whole point was interoperability and you've $%#$@#ed that up. 1 user complain in 15months of operations. You call that $%#$@#ed that up while IIRC I was the first implementor ??? Now I am the one disapointed ! I think your action threatens the whole enterprise and it's deplorable. What will the spec be completed ? So far I have seen no movement since Aug 01, I raised my point shortly after because I got users reporting to me they got confused by the distinction (because initially I tried to make the separation). At that point I basically received an answer without content. So I merged both notions an had no problem until the beginning of this thread. In retrospect saying the course of my actions is to threatens the XML Catalog deployement could only be looked at with amazement for example from the Gnome community, damn, I got beaten and had to fight there to have them deployed . To be frank, it's my turn to be disappointed and frustrated :-( I take patches usually !!! Usually people who have troubles send me patches or report the problems they face, then I fix them. Show me a final version [*] of the XML Catalog spec and I will either fix the problem or remove the support. Daniel [*] http://www.oasis-open.org/committees/entity/ doesn't show any update since the 06 August 2001. -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 01:58:30PM -0600, Paul Grosso wrote: 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 spec says it's an URI-Reference. It references the RFCs explaining how to compute the final URI from those references. The fact that there are restrictions from the full set admited as the URI-References input doesn't mean that the mechanism should not be used. The only meaning is that one cannot try to point to a subsection of the target resource, period. It does not mean that the URI-Reference to URI mechanism by composition to the base must be voided or be made specific. 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. When there is a public ID, then the public ID may point to something else. In the case where there is twice the exact same system ID I don't see any reasonnable justification to distinguish those. You're asking for the same resource, why would you magically get different results ? Moreover when there are both System ID and Puyblic ID the XML Catalog spec clearly separate the lookup processing by public and system ID. As a result the work to be done on a system ID is exactly similar to the one one need to take for another URI reference except the identifiers in the catalog need to be magically different. I very much disagree with your broken assertion, Daniel. I ask of resource A, then A again, and get different results without the actual resource having changed in the meantime. Yeah I think this is broken, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
RE: DOCBOOK-APPS: RE: XML catalog resolution problems
At 12:27 2002 10 30 +0100, Jeanson Mauritz wrote: When trying xsltproc, I found that it accepts and resolves system entries for stylesheets in catalog files. As I take it, this is not the correct behaviour. You are correct, xsltproc is not in compliance with the XML Catalog spec. The XML Catalog spec makes it clear that system entries are for resolving external identifiers (production 75 in XML) and clearly says about URI entries [1]: 4.2. URI Entries Other URI references, for example namespace names, stylesheets, included files, graphics, and hypertext references, simply identify other resources. The input to a resolver that locates resources is simply the original URI reference. For the purposes of resolving URI references, the following entries are considered: The uri entry indicates that an entity manager must use the associated URI reference to locate the resource. The rewriteURI entry ... The delegateURI entry ... Section 7 Catalog Resolution Semantics has two sections, one each describing External Identifier Resolution and URI Resolution in great detail. Again it is made clear that system entries are only for resolving external identifiers and cannot be used for resolving other URIs such as those for stylesheets. It is wrong to use the system entries to resolve other URI references [such as] stylesheets I believe Daniel Veillard is well aware of this, but he disagrees with the XML Catalog spec in this regard and has therefore written xsltproc to do what he thinks it should instead of to be compliant with the OASIS Committee Specification. If you want to write XML catalogs that comply with the spec and work interoperably in compliant implementations, you would be wise to use the system and uri entry types accordingly. paul [1] http://www.oasis-open.org/committees/entity/spec.html#s.uri.ent [2] http://www.oasis-open.org/committees/entity/spec.html#s.semantics
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 09:28:44AM -0600, Paul Grosso wrote: At 12:27 2002 10 30 +0100, Jeanson Mauritz wrote: When trying xsltproc, I found that it accepts and resolves system entries for stylesheets in catalog files. As I take it, this is not the correct behaviour. You are correct, xsltproc is not in compliance with the XML Catalog spec. The XML Catalog spec makes it clear that system entries are for resolving external identifiers (production 75 in XML) and clearly says about URI entries [1]: And I have said to the XML Catalog comitee that an URI Reference is an URI-Reference and that having to distinguish arbitrarilly one done from a DOCTYPE entry from one done from an xi:include href entry doesn't make any sense to me, and that I would not support the distinction in my software unless getting a meaningful reason to distinguish those. I haven't received any justification yet from the commitee about the reason to distinguish those exept they are different, no sorry ... I see ZERO reason why the two following URI-Reference made from a single XML entity should lead to using different resource for http://example.com/foo.dtd: --- DOCTYPE foo SYSTEM http://example.com/foo.dtd foo xi:include href=http://example.com/foo.dtd; parse=text/ /foo --- This distinction is extremely confusing, and so far can't be justified I really don't see why it's there and the intended purpose. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
At 11:12 2002 10 30 -0500, Daniel Veillard wrote: On Wed, Oct 30, 2002 at 09:28:44AM -0600, Paul Grosso wrote: The XML Catalog spec makes it clear that system entries are for resolving external identifiers (production 75 in XML) and clearly says about URI entries [1]: And I have said to the XML Catalog comitee that an URI Reference is an URI-Reference and that having to distinguish arbitrarilly one done from a DOCTYPE entry from one done from an xi:include href entry doesn't make any sense to me, and that I would not support the distinction in my software unless getting a meaningful reason to distinguish those. I haven't received any justification yet from the commitee about the reason to distinguish those exept they are different, no sorry ... Well, when Microsoft said I see no reason not to support empty end tags (i.e., /) in XML, people rose in protest. One justification is that this is the standard, and you are refusing to follow it. 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. XML has no concept of a URI. It only has a concept of ExternalID with a SystemLiteral. Furthermore, XML's SystemLiteral cannot have a fragment ID: It is an error for a fragment identifier (beginning with a # character) to be part of a system identifier. So the datatype of the systemId entry is different from the datatype of the uri entry. Another reason it makes good architectural sense to have two different entry types. I see ZERO reason why the two following URI-Reference made from a single XML entity should lead to using different resource for http://example.com/foo.dtd: --- DOCTYPE foo SYSTEM http://example.com/foo.dtd foo xi:include href=http://example.com/foo.dtd; parse=text/ /foo --- In addition to my explanation above--and the fact that your example is not going to be a common one, so such redundancy is in fact going to be rare--there are other good reasons why these two URIs might want to be treated differently. 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. 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. paul
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Wed, Oct 30, 2002 at 11:25:02AM -0600, Paul Grosso wrote: I haven't received any justification yet from the commitee about the reason to distinguish those exept they are different, no sorry ... Well, when Microsoft said I see no reason not to support empty end tags (i.e., /) in XML, people rose in protest. One justification is that this is the standard, and you are refusing to follow it. Thanks for the association, greatly appreciated :-((( There was technical reason exposed for refusing / once being that redudancy allowed to catch errors. There was support for having clearly marked ending tags outside of the XML Working Group, I have yet to see one user which is not confused by the SYSTEM/URI distinction. I mean real user, the categories of persons I tend to get them to adop XML, and use Catalogs, not a 20 years veteran specialized in the field. 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. 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. XML has no concept of a URI. It only has a concept of ExternalID with a SystemLiteral. It does expose the System ID as being an URI reference, sorry reread 4.2.2, it does reference RFC 2396 and Co. Furthermore, XML's SystemLiteral cannot have a fragment ID: Which is precisely a rule it adds at the semantic level on that string associating it as an URI precisely ! So the datatype of the systemId entry is different from the datatype of the uri entry. Another reason it makes good architectural No both are a URI References. XML may impose some restriction on the final URI generated. XInclude also expose sonme restrictions, but those are two object of the same kind with the same properties and with the same base they ought to point to the same resource ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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
DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Daniel Veillard [EMAIL PROTECTED] was heard to say: | On Wed, Oct 30, 2002 at 09:28:44AM -0600, Paul Grosso wrote: | You are correct, xsltproc is not in compliance with the XML Catalog spec. [...] | And I have said to the XML Catalog comitee that an URI Reference is | an URI-Reference and that having to distinguish arbitrarilly one done | from a DOCTYPE entry from one done from an xi:include href entry | doesn't make any sense to me, and that I would not support the distinction | in my software unless getting a meaningful reason to distinguish | those. You are, of course, free to do anything you please. Committees of like-minded individuals gather together to produce specifications for many reasons: - - To allow greater interoperability between products and applications - - To increase market share by allowing products to compete on implementation - - To reduce the number of things that end-users have to know, increasing ease-of-use To name but a few. In the course of producing specifications, different points of view are presented, both within the committee and from the community at large. Some of those points of view are in conflict. Through discussion, debate, and persistence, effective committees eventually reach a consensus position. Often, that position varies from the position that different members of the committee (and the community at large) consider ideal but the benefit of the specification as a whole is seen as more important. In this particular case, the Entity Resolution TC discussed your objections at length. Eventually we reached the consensus opinion that system identifiers and URIs are not the same thing and that the distinction in the spec was valuable. I've served on lots of committees, I've argued lots of positions. Sometimes I've argued persuasively and seen issues resolved in ways that are consistent with my point of view. Sometimes I've argued less persuasively (or at least less successfully) and seen issues resolved in ways that are inconsistent with my point of view. C'est la vie. The whole process is a pointless waste of time if, at the end of the day, individuals or companies are going to produce implementations that match their own points of view rather than the consensus view of the published specifications. I am, to be frank, disappointed and frustrated that you've blown a great big hole in a smooth operation of XML Catalogs. The whole point was interoperability and you've $%#$@#ed that up. I think your action threatens the whole enterprise and it's deplorable. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | More men become good through http://www.oasis-open.org/docbook/ | practice than through Chair, DocBook Technical Committee | nature.--Democritus of Abdera -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE9wEGkOyltUcwYWjsRAntmAJ9di42KhHQNTqXsi2jfoJqz0FrcSQCbB0OY wIZ0HlElQdSRvI+4bjcTshw= =pfv2 -END PGP SIGNATURE-
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
As a practical user, I would like to request that the XML catalog implementation in xsltproc adhere to the published standard, whether or not you agree with the standard. Standards allow for interoperability. I would like to use the same XML catalog with different processors. I can't do that if the processors don't conform to the behavior prescribed by the standard. If you don't want to conform to the standard, call your implementation something else (Veillard Catalogs has a nice ring to it 8^). Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED]
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
Bob Stayton wrote: As a practical user, I would like to request that the XML catalog implementation in xsltproc adhere to the published standard, whether or not you agree with the standard. Standards allow for interoperability. I would like to use the same XML catalog with different processors. I can't do that if the processors don't conform to the behavior prescribed by the standard. If you don't want to conform to the standard, call your implementation something else (Veillard Catalogs has a nice ring to it 8^). +1 -- - Jirka Kosek e-mail: [EMAIL PROTECTED] http://www.kosek.cz
DOCBOOK-APPS: RE: XML catalog resolution problems
-Original Message- From: Norman Walsh [mailto:ndw;nwalsh.com] Sent: Friday, October 25, 2002 7:07 PM To: Jeanson Mauritz Cc: [EMAIL PROTECTED] Subject: Re: XML catalog resolution problems -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, I'm offline, and I don't recall what -u means... According to the Saxon documentation: Indicates that the names of the source document and the style document are URLs; otherwise they are taken as filenames, unless they start with http: or file:, in which case they are taken as URLs. | 2. use uri instead of system in the catalog file, Right. Stylesheet locations *are* general URIs, they aren't system identifiers. Does that mean that system shouldn't be used for stylesheets in a catalog file? In Bob Stayton's catalog tutorial, this catalog has a system entry: ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS/DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog system systemId=docbook.xsl uri=/usr/lib/xml/docbook-xsl-1.50/html/docbook.xsl/ /catalog Is this not correct? | 3. prepend the xml file name with file: on the command line, and | 4. use a system ID with full path to the DTD (or a public ID). The DTD location and the stylesheet location aren't related, so I'm confused. Sorry if I caused any confusion. If I omit the doctype declaration in my XML file, item 4 does not apply. If I have a doctype declaration, I must use a public ID (since resolution of public IDs works), or a system ID with the full DTD path (since resolution of system IDs does not work). Regards, Mauritz Jeanson The ebxml-dev list is sponsored by OASIS. To subscribe or unsubscribe from this elist use the subscription manager: http://lists.ebxml.org/ob/adm.pl
Re: DOCBOOK-APPS: RE: XML catalog resolution problems
On Mon, Oct 28, 2002 at 08:26:07AM +0100, Jeanson Mauritz wrote: -Original Message- From: Norman Walsh [mailto:ndw;nwalsh.com] Sent: Friday, October 25, 2002 7:07 PM To: Jeanson Mauritz Cc: [EMAIL PROTECTED] Subject: Re: XML catalog resolution problems -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, I'm offline, and I don't recall what -u means... According to the Saxon documentation: Indicates that the names of the source document and the style document are URLs; otherwise they are taken as filenames, unless they start with http: or file:, in which case they are taken as URLs. | 2. use uri instead of system in the catalog file, Right. Stylesheet locations *are* general URIs, they aren't system identifiers. Does that mean that system shouldn't be used for stylesheets in a catalog file? In Bob Stayton's catalog tutorial, this catalog has a system entry: ?xml version=1.0? !DOCTYPE catalog PUBLIC -//OASIS/DTD Entity Resolution XML Catalog V1.0//EN http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd; catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog system systemId=docbook.xsl uri=/usr/lib/xml/docbook-xsl-1.50/html/docbook.xsl/ /catalog Is this not correct? In rereading the XML Catalog specification, I think my stylesheet examples are not correct. Stylesheet references are URIs, not system identifiers. I think I need to redo the catalog chapter. Sorry if I created confusion. -- Bob Stayton 400 Encinal Street Publications Architect Santa Cruz, CA 95060 Technical Publications voice: (831) 427-7796 Caldera International, Inc. fax: (831) 429-1887 email: [EMAIL PROTECTED]
DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | This is the current score: | | A. Resolution of system IDs: does not work at all. | | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, | 2. use uri instead of system in the catalog file, | 3. prepend the xml file name with file: on the command line, and | 4. use a system ID with full path to the DTD (or a public ID). That's very odd. Try turning up the verbosity of the resolver. A setting of 4 or more should produce a complete dump of everything it tried to do. Are you using real saxon or instant saxon? Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Until death, it is all http://www.oasis-open.org/docbook/ | life.--Cervantes Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE9uXndOyltUcwYWjsRAvt2AKCeyJrDu46POatLLoJyda/QQjiWFACfVyaL gjzrrHjmPR6jQnxbSzQqLwk= =LWuJ -END PGP SIGNATURE-
DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | B. Resolution of stylesheet locations: works only if I | 1. use Saxon's -u flag, I'm offline, and I don't recall what -u means... | 2. use uri instead of system in the catalog file, Right. Stylesheet locations *are* general URIs, they aren't system identifiers. | 3. prepend the xml file name with file: on the command line, and | 4. use a system ID with full path to the DTD (or a public ID). The DTD location and the stylesheet location aren't related, so I'm confused. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | The effects of weakness are http://www.oasis-open.org/docbook/ | inconceivable, and more prodigious Chair, DocBook Technical Committee | than those of the most violent | passions.--Cardinal De Retz -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE9uXo3OyltUcwYWjsRApGrAKCDHUQJWH9NVXuf8YePvqgPWm1hjgCgihN9 nI13BSli72TiPoYg49dmbFQ= =iOMv -END PGP SIGNATURE-
DOCBOOK-APPS: Re: XML catalog resolution problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Jeanson Mauritz [EMAIL PROTECTED] was heard to say: | [Schlienger, Marc] for stylesheets I suggest you put | local links | into the required ones, for instance in chunk.xsl there is normaly: | xsl:import | href=http://docbook.sourceforge.net/release/xsl/current/html/ | docbook.xsl/ | | comment it out and replace it with | | xsl:import href=docbook.xsl/ | | Well, you might say that this is not nice, but it works... | | Tell me if this helps... | | Marc | | Well, the whole point of catalogs is that you don't need to change any | local paths at all (except in the catalog file itself, of course). | My basic problem would still be unsolved. Right. You want uriname=http://docbook.sf.net/release/xsl/current/html/docbook.xsl; uri=/path/to/local/xsl/html/docbook.xsl/ In your catalog to do the right thing. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | Syllables govern the world.--John http://www.oasis-open.org/docbook/ | Selden Chair, DocBook Technical Committee | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 http://mailcrypt.sourceforge.net/ iD8DBQE9uXppOyltUcwYWjsRApRQAJwL3+nKI6dSAU+yHsifdLfUmNqMJACfVyd/ tirP0HALPZogv7cRVqSqm0M= =6SP5 -END PGP SIGNATURE-
