"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Configuring XML Processors

Contents

Related pages



Configuring your processor to use local copies of the schemas rather than attempting to get them from remote locations depends on which software you are using but most can be configured to use an OASIS Standard XML Catalog file. SimonCox uploaded the one he uses at XmmlSVN:localcatalog.xml.

XML IDE's

XMLSpy

XMLSpy can be configured to use an XML Catalog, by putting a document called "CustomCatalog.xml" in the same directory as the XMLSpy.exe executable - typically C:\Program Files\Altova\XMLSpy2007.

Warning: Older versions of XMLSpy are buggy and inconsistent

There is a problem with XMLSpy (version older than 2007 sp3) with some recursive xsd (although they are pretty much all recursive as far as I can tell). The problem is discussed here http://www.altova.com/forum/default.aspx?g=posts&t=7404.

The problem is simply that the very same xsd validates or does not validate depending of the display mode in XMLSpy. For instance, Gsml.xsd does not validate when in graphical editor (a.k.a Schemas/WSDL mode), but validates fine when it text mode.

If you don't open directly this gsml.xsd file (for example, when one edits an instance and refers to geosciml.xsd - which includes all the other xsd), there are not problems. The problem has been resolved in the latest 2007 r3 version.

This has been documented in the readme file located in the same svn directory as the xsd.

-- EricBoisvert - 31 Jul 2007

oXygen

(Note: oXygen uses Xerces-J internally.)

You can configure oXygen to use a catalog file like the above under Options / Preferences / XML / XML Catalog .

I found that using rewriteURI entries in an XML catalog file didn't work using oXygen as my validating application. Instead I had to use rewriteSystem entries. The example Catalog above which includes both styles works for me using oXygen.

Warning: on oXygen Catalog Templates

As per this long support thread with oXygen 8.2 there's a bug when you use their templates to create your catalog
The system ID of an XML Catalog 1.1, that is "http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd" is not resolved correctly to the internal schema which is shipped with oXygen when the catalog file is parsed. The fix will be included in the next version of oXygen.

To avoid the error please remove the DOCTYPE declaration from your XML Catalog 1.1 files which you added in Options -> Preferences -> XML -> XML Catalog. After removing the DOCTYPE declaration the catalog files will be used correctly for entity and URI resolution.

oXygen and Relative schemaLocation

A recent appeal for help led me on quite a journey trying to work out why it wasn't handling relative locations. Finally confirmed the oXygen workflow is such that the relative uri is expanded to a full path before it gets to the catalog, hence you must customise your catalog to match these expansions.

Note: localcatalog.xml has been updated to include this fix - svn rev 1778

-- AndyDent - 09 Oct 2007

Stylus Studio

(Note: Stylus Studio uses Xerces-C++ internally.)

Add a catalogue document like this one to the "project". Right-click on it in the Project window, and select "Use Document as Catalog".

-- SimonCox - 12 Jul 2007

General XML Processing environments

Java

Some notes on configuring Java applications to use an XML Catalog are in this article but I haven't tried this myself yet. Can anyone who does try it out report their results here? Also note that the article says
Although not explicitly marked as a system identifier we can use a catalog with a system element to associate the schema with a local copy.
which accords with oXygen's behaviour.

-- MarcusSen - 11 Jul 2007


Discussions

OASIS XML Catalog format

It has become apparent that different processors interpret the OASIS XML Catalog specification differently in how it applies to the location URL's in schemaLocation attributes. Hopefully including both rewriteSystem and rewriteURI elements in any Catalogs we put up will work so we don't have to bother ourselves with which is correct but, for general interest below is some discussion on the subject (-- MarcusSen 26 Jul 2007)


MarcusSen:

From the XML Catalog specification I believe that oXygen's implementation is wrong, but need to investigate further.


AndyDent:

disagree - oXygen has been criticised as possibly not obeying rewriteSystem rules.

I suspect in fact that it enforces rules that others have treated sloppily.

http://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#element-rewriteURI says

6.5.10. The rewriteURI Element

The rewriteURI element rewrites the beginning of a URI reference that is not part of an external identifier.

...

7.1.2. Resolution of External Identifiers

Resolution follows the steps listed below, proceeding to each subsequent step if and only if no other action is indicated.

Resolution begins in the first catalog entry file in the current catalog entry file list.

If a system identifier is provided, and at least one matching system entry exists, the (absolutized) value of the uri attribute of the first matching system entry is returned.

If a system identifier is provided, and at least one matching rewriteSystem entry exists, rewriting is performed.

Conclusion - use both rewriteURI and rewriteSystem

Given the sloppy support of some processors, the possible ambiguities in the specification and certainly lack of informative clarification, my recommendation is people use both rewriteURI and rewriteSystem in their catalogs and include a comment explaining why, so well-meaning users with just a single tool don't clean up.


MarcusSen:

I concur with the conclusion to use both elements. The part of the specification which makes me think that using rewriteSystem is not strictly correct is in Section 2:

The term external identifier is to be interpreted as defined in Production 75 of XML. External identifiers have two parts, an optional public identifier and a system identifier. The terms public identifier and system identifier in this OASIS Standard always refer to the respective part of an external identifier. Note

All system identifiers are URI references, but not all URI references are system identifiers. A system identifer is always logically part of an external identifier, even when the public identifer is not provided.

By this definition it seems to me that the location members of the schemaLocation attributes do not count as system identifiers. It would make more sense for them to be counted as system identifiers as the role they fulfill is the same. However, it seems the OASIS spec wasn't written with XML Schema in mind; I've no idea whether they have any plans to revise this in a later version.

-- SimonCox - 06 Feb 2009
 
Topic revision: r5 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).