XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Understanding the scope of XML catalog

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS