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

Thank you, Gerrit and John, for the prompt responses.

At 2019-03-02 04:46 +0100, Imsieke, Gerrit, le-tex wrote:
The namespace URI is just an identifier and does not associate a schema with the instance.
Yes, indeed. As I have taught before. A namespace name is just a string. oXygen provides a nice feature of associated a document element in a specific namespace with a schema location and I looked into the XML Catalog spec to see if such was available there.

When I saw the cited references for namespace strings, I thought I was all set. I worded the subject line of this specifically to understand whether the scope of catalogs included the namespace URI string of the document element.

Apparently not, and it is good to have minds smarter than mine tell me so. Thank you.

You probably need to provide an xsi:schemaLocation URI
The environment I was trying to create with a catalog was specifically to address those instances that do not have such an attribute (or already have an attribute from a foreign environment) and are read-only. When a client sends a UBL document to an intermediary or to a trading partner, it would be nice to do schema validation for integrity, without needing inspection to determine which of the 81 document schemas to apply. Of course if one knows the document element, one knows which of the 81 schemas to use.

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.
Sure ... but the instance from the generating system may not have the schema location with which to map. And, again, it is from a foreign environment and so could be any arbitrary string and so would not already be in my catalog.

oXygen, for example, both supports catalogs and can use namespace URIs to associate schemas with document instances.
BINGO! Yes, that is what led me to try to use catalogs in the same fashion.

Apparently oXygen is selective with respect to which kinds of URIs it maps.
...
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
Decisions I can respect easily. What I'm looking for is a normative behaviour I can convey in the UBL documentation to readers to help them configure their environments.

I already tell everyone to buy and use oXygen, but I cannot say that in an ISO standard!

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).
I grant that and I've always understood that. What I was hoping was that the catalog documentation was telling me of an available mapping mechanism with which to impose such an association, as is available in oXygen document type associations.

I wonder if Norm could be convinced to consider broadening the scope in a new XML Catalog 1.2?

Again, gentlemen, as always, I appreciate the discourse!

. . . . . . . Ken

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ |
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) |



[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