Re: [xml-dev] Understanding the scope of XML catalog

["Imsieke, Gerrit, le-tex" <gerrit.imsieke@le-tex.de>]

Hi Ken,

The namespace URI is just an identifier and does not associate a schema 
with the instance.

You probably need to provide an xsi:schemaLocation URI to tell the 
parser/reader where the schema is, and a catalog-resolving validating 
parser should in fact respect a catalog entry in which you provide the 
location of the associated schema on your hard disk.

I'm not sure what the catalog spec authors had in mind when they wrote 
that the uri element (and related elements such as rewriteURI) can be 
used to map namespace names. Maybe they wanted me to allow to provide an 
alias for a namespace URI, like this:
<uri name="foobar" uri="http://www.tei-c.org/ns/1.0"/>
But this would amount to using the catalog entry the other way around, 
compared to what you tried to achieve.

oXygen, for example, both supports catalogs and can use namespace URIs 
to associate schemas with document instances. So I tried to use this 
foobar->TEI mapping above to get oXygen to use the TEI schema as per its 
default document association rules when I start a document with <TEI 
xmlns="foobar"> instead of <TEI xmlns="http://www.tei-c.org/ns/1.0";>. 
Yet apparently oXygen does not respect the catalog mapping above to 
resolve 'foobar' to the actual namespace URI and then apply its document 
type association mechanism. Apparently oXygen is selective with respect 
to which kinds of URIs it maps.

[continued below]

On 02.03.2019 03:06, G. Ken Holman wrote:
> Fellow XML-Dev'ers,
>
> I'm trying to better understand the use of an XML catalog to find a 
> schema for validation.
>
> In addition to PUBLIC and SYSTEM identifier resolution, I understand 
> that the <uri> element will map namespace names to locations per:
>
> Introduction
> https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.intro 
> "Mapping the URI reference of a resource (a namespace name, stylesheet, 
> image, etc.) to another URI reference."
>
> URI Entries
> https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.uri.ent 
> "URI references that are not part of an 
> <https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.ext.ent>external 
> identifier, such as namespace names, stylesheets, included files, 
> graphics, and hypertext references, simply identify other resources. 
> They are resolved using URI entries as described below."
As stated above, I think tools can be selective in which types of 
resources they use catalog resolvers for. For example, Saxon uses it 
only for resolving references to other XML resources: 
https://www.saxonica.com/documentation/#!sourcedocs/xml-catalogs
“The catalog is NOT currently used for non-XML resources, including 
query modules, unparsed text files, collations, and collections.”

So of the list of possibly resolvable items that you quoted from the 
catalog spec, Saxon will only use the catalog to resolve XSLT 
imports/includes, schema documents, XML resources requested by doc(), 
but not, for example, by unparsed-text() or file:read-binary() 
(https://www.saxonica.com/documentation/#!functions/expath-file/read-binary).
So even if I configure the catalog to map
<uri name="test.png" uri="../img/actual-location.png"/>
and use
<xsl:sequence select="file:read-binary('test.png')"/>
it will throw an error "file:not-found: No file exists at test.png" 
because it is not configured to use the XML catalog for "graphics". So I 
guess that just like binary locations, common XML catalog resolvers or 
rather, the tools that employ these resolvers, simply omit namespace URI 
mappings, binary file locations, etc. from the resolvable resources, and 
restrict themselves to XML resources.

Returning to what I said above: But even if the catalog spec were 
prescriptive and required resolvers to consider your "namespace to local 
resource" mapping, a catalog-resolving parser would still not be able to 
find the schema since namespace URIs don't resolve to schema locations 
(except when the namespace URI and the schema location happens to be 
identical).

Such a namespace-resolving parser would rather complain, if you managed 
to point it to the schema by other means (xsi:schemaLocation), that the 
catalog-resolved namespace URI of the top-level element, 
'maindoc/UBL-Invoice-2.2.xsd', does not correspond to the namespace URI 
that is expected by the schema, which still is 
'urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'.

Gerrit

> And so I created the following to map the UBL namespace name to the URI 
> of the schema and I've confirmed the relative location from the catalog 
> file:
>
>     <uri name="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
>          uri="maindoc/UBL-Invoice-2.2.xsd"/>
>
> And my document begins with:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
>          
> xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" 
>          
> xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"> 
>          <cbc:UBLVersionID>2.1</cbc:UBLVersionID>
>          <cbc:ID>TOSL108</cbc:ID>
>          <cbc:IssueDate>2009-12-15</cbc:IssueDate>
>
> Yet using XJParse, I'm not able to validate my document:
>
> ~/t/os-UBL-2.2 $ xjparse -c xsd/UBL-2.2-catalog.xml -s ~/t/j.xml
> Attempting well-formed, namespace-aware parse
> Error:file:///Users/admin/t/j.xml:4:83:cvc-elt.1.a: Cannot find the 
> declaration of element 'Invoice'.
> Parse succeeded (0.39) with 1 error and no warnings.
> ~/t/os-UBL-2.2 $
>
> Can anyone see where I'm going wrong? This would seem so simple. Based 
> on the documentation I'm expecting the namespace name of the document 
> element of the instance to be matched in the catalog to the URI of the 
> schema. Is that out of bounds of the specification?
>
> I'm clearly missing something.
>
> Thanks for any help anyone can be.
>
> . . . . . . Ken
>
>
> --
> Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
> Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
> Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@le-tex.de, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt