xml editor

[asaremba]

When I run a transformation scenario with Saxon-EE and lax validation, the validation is not performed because Saxon-EE is unable to locate the schema file.

In the instance document, the schema is referenced via

Code: Select all

<OV-IE-AS
  xsi:noNamespaceSchemaLocation="http://www.siemens.com/nars/v2t/OV-IE-AS" ...>...

The system identifier is mapped to a file system URL in a catalog file that is listed in the Oxygen XML Catalog Preferences (where it is found as you can see from the following output).

These are messages I get when I set verbosity to "All messages":

Code: Select all

Resolved system: http://www.siemens.com/nars/v2/OV-IE-AS   file:/C:/mtiroot/NARS_workspace/xml/schema_flat/v2/ov-ie_v2.xsd
Public: null System: http://www.siemens.com/nars/v2/OV-IE-AS = file:/C:/mtiroot/NARS_workspace/xml/schema_flat/v2/ov-ie_v2.xsd
Could not resolve URI:

What is this? First I am told that the system identifier was resolved correctly, two lines later the URI (which one?) cannot be resolved? (In the preferences, Prefer=system is set.)

With lax validation, the effect is that the attribute default values I need are not inserted into the document. If I set schemaValidation="strict" in the Saxon configuration file, I get different errors:

Code: Select all

org.apache.commons.httpclient.HttpException: 404 Not Found for: http://www.siemens.com/nars/v2/OV-IE-AS - 404 Not Found for: http://www.siemens.com/nars/v2/OV-IE-AS
Validation will continue without the schema at http://www.siemens.com/nars/v2/OV-IE-AS
Cannot validate <OV-IE-AS>: no element declaration available
Start location: 3:170
URL: http://www.w3.org/TR/xslt20/#err-XTTE1510


Looks like Saxon-EE does not even read the catalog file!? Interestingly enough, this is not the case when I use Saxon-EE as validator in a validation scenario, all other things being equal! Although it produces the same strange "Could not resole URI" message like above, its concluding statement is "Validation succesful". (Yes, in exactly this spelling!)

This is the content of the Saxon configuration file:

Code: Select all

<configuration xmlns="http://saxon.sf.net/ns/configuration" edition="EE">
<!--
    <global schemaValidation="strict" expandAttributeDefaults="true" />
-->
    <global expandAttributeDefaults="true" />
    <xsd useXsiSchemaLocation="true" version="1.0"/> 
</configuration>

[adrian]

Hello,

The message "Could not resolve URI:" tells me that some URI(most probably "http://www.siemens.com/nars/v2/OV-IE-AS") cannot be resolved by the catalog resolver.

Have you resolved both the systemID and the URI in the XML catalog ?
e.g.

Code: Select all

<system systemId="http://www.siemens.com/nars/v2/OV-IE-AS" uri="file:/C:/mtiroot/NARS_workspace/xml/schema_flat/v2/ov-ie_v2.xsd"/>

<uri name="http://www.siemens.com/nars/v2/OV-IE-AS" uri="file:/C:/mtiroot/NARS_workspace/xml/schema_flat/v2/ov-ie_v2.xsd"/>

Regards,
Adrian

[asaremba]

No, I had not done this, and adding an additional uri entry to the already existing system entry in the catalog.xml solved the problem. But I am not really satisfied with this solution (or rather workaround) because I've got the impression that the catalog standard is interpreted differently by each tool vendor.

The standard (OASIS Standard V1.1, 7 October 2005) distinguishes between system identifiers and URI references:

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.

Some time ago, Eliot Kimber stated (http://www.mail-archive.com/oxygen-user ... 00131.html):

Also, it appears that the oXygen resolver is resolving noNamespaceSchemaLocation= values via SYSTEM catalog entries and not URI entries. I don't think this is correct given that noNamespaceSchemaLocation and schemaLocation are not entity references but are references to non-entity resources. They should be resolved via URI entries exclusively.

This sounds completely logical to me. But most tools (Oxygen, XMetaL, XML Spy) happily use the system entry, and the Oxygen User manual explicitly states:

An XML catalog can be used also to map a W3C XML Schema specified with an URN in the xsi:schemaLocation attribute of an XML document to a local copy of the schema. For example if the XML document specifies the schema with:

<topic xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="urn:oasis:names:tc:dita:xsd:topic.xsd:1.1">...

the URN can be resolved to a local schema file with a catalog entry like:

<system systemId="urn:oasis:names:tc:dita:xsd:topic.xsd:1.1"
uri="topic.xsd"/>

Even Saxon-EE seems to be a bit unsure whether it should use the system or the uri entry - as I stated in my original posting, using Saxon-EE in an Oxygen validation scenario works without a uri entry; but in a transformation scenario I need to add the uri entry!?

Is this a Saxon inconsistency or is it caused by the way you have integrated Saxon-EE in Oxygen?

[adrian]

It's true that there is some confusion as to how the schema location is resolved by various implementations of XML catalog resolvers.

While I do agree that it should be resolved as an URI(as the specification says), the problem is that this incorrect way of being resolved as a systemID has been propagated by various tools for years.
To fix this and switch to URI-only would mean to break the functionality of all the catalogs that have been configured specifically to work this way. A solution is to attempt to resolve it first as a systemID(to keep backwards compatibility) and then as a URI(as it says in the specification).

The inconsistency of Saxon-EE in this regard is indeed caused by the Oxygen integration.
Saxon-EE only needs the URI to be resolved as seen in the transformation.
However, when Oxygen validates it resolves the schema location as a systemID before starting the validation itself.

I've logged this problem to our issue tracking tool and included your comments. We will analyse the issue and provide a fix in a future version of Oxygen.

Regards,
Adrian

[asaremba]

Thank you for the helpful explanation. I agree that backwards compatibility is often a necessary evil. Microsoft is even known to simulate old bugs in new versions of their OSs when they detect a buggy application that relies on them, so how could I blame you?

However, a hint in the documentation would certainly be useful. And may I suggest to use a fallback solution that first looks for the correct parameter and only then (in the case of failure) tries the one that has been mistakenly used by so many, including myself.

[adrian]

I'll make sure this gets documented.
Also, you're right, we should first try to resolve the schema location as an URI and only if that fails use the fallback to systemID.

I've logged your comments to our issue tracking tool and we will address this in a future version of Oxygen.

This is not going to make it in v12, since it's very close to the end of the beta stage. Hopefully in 12.1 it should be addressed.

Regards,
Adrian

[adrian]

Hi,

This has been implemented in Oxygen v13.2.

Now the schema location is attempted to be resolved in this order:
- through the URI mappings
- if the option XML > XML Catalog, Resolve schema location also through system mappings is enabled(it is by default), it is attempted to be resolved through the system mappings.
- if the option XML > XML Catalog, Process namespaces through URI mappings for XML Schema is enabled(by default it is disabled), it is attempted to be resolved through the URI mappings by using namespaces.

Regards,
Adrian