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:
> subscribe:
> 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
, 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
