Saxon-EE fails to locate schema

[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

[susi]

Hi,
The defined XML Catalog already works fine for "direct validation" with Saxon-EE 9.4.0.4.

But when doing a XSL transform with the same (schema-aware) XSL processor the XML Catalog is not deployed, I get the following error message:

Code: Select all

Engine name: Saxon-EE 9.4.0.4

Severity: error

Description: Cannot validate <{...namespace}element>: no element declaration available

Start location: 2:59

URL: http://www.w3.org/TR/xslt20/#err-XTTE1510

Where could I define an XML catalog for the Saxon? I didn't find an appropriate attribute in the "Saxon configuration file".

Any hints appreciated.

Kind regards...
Susi

[sorin_ristache]

Hi Susi,

The same XML catalogs are used for the validation of the XSLT stylesheet and for the XSLT transformation. You don't have to register your custom XML catalog in a Saxon configuration file, you just add it to the user preferences and Oxygen will take care to pass it to Saxon for both the validation and the transformation of XSLT stylesheets. Did you add an XML catalog in the Options -> Preferences dialog box, the panel XML / XML Catalog? Do you use Saxon-EE 9.4.0.4 for both validation and transformation? Please note that the default validator for XSLT 2.0 stylesheets is Saxon-PE, not Saxon-EE, and it can be configured in the same Preferences dialog box, the panel XML / XSLT-FO-XQuery / XSLT. Did you change it to Saxon-EE in the panel XML / XSLT-FO-XQuery / XSLT?

If you added your XML catalog to the user preferences and you are sure that it specifies the schema location correctly (that is the validation finds the schema correctly through the XML catalog) you can send us some sample files for reproducing the problem (a sample XSLT stylesheet and an XML document that should be processed by the stylesheet, the XML catalog file).


Regards,
Sorin

[susi]

Hi Sorin,
thanks for the quick answer and the really good hints.

The same XML catalogs are used for the validation of the XSLT stylesheet and for the XSLT transformation. You don't have to register your custom XML catalog in a Saxon configuration file, you just add it to the user preferences and Oxygen will take care to pass it to Saxon for both the validation and the transformation of XSLT stylesheets.

That sounds like good news.

Did you add an XML catalog in the Options -> Preferences dialog box, the panel XML / XML Catalog?

Yes, already done, as "Project Options".

Do you use Saxon-EE 9.4.0.4 for both validation and transformation?

Yes, already done.

Please note that the default validator for XSLT 2.0 stylesheets is Saxon-PE, not Saxon-EE, and it can be configured in the same Preferences dialog box, the panel XML / XSLT-FO-XQuery / XSLT. Did you change it to Saxon-EE in the panel XML / XSLT-FO-XQuery / XSLT?

No, I did not have to change it. It comes with the following pre-definitions:

• XSLT 1.0: Saxon6.5.5
  XSLT 2.0: Saxon-EE 9.4.0.4
  XSLT 3.0: Saxon-PE 9.4.0.4

I currently define XSLT 2.0 stylesheets.

If you added your XML catalog to the user preferences and you are sure that it specifies the schema location correctly (that is the validation finds the schema correctly through the XML catalog) you can send us some sample files for reproducing the problem (a sample XSLT stylesheet and an XML document that should be processed by the stylesheet, the XML catalog file).

Yes, I will send you some sample files. But first I will define a minimum working example in order to not send sensible data.
Kind regards...
Susi

[adrian]

Hello,

In case anyone else encounters this...
Saxon-HE/PE/EE is configured for strict validation of the source file: Options > Preferences, XML / XSLT-FO-XQuery / XSLT / Saxon / Saxon-HE/PE/EE, "Saxon EE specific options", "Validation of the source file:", "Schema validation".
The problem is that the Saxon-EE strict validation of the source file does not benefit from the same catalog resolver mechanism that Oxygen provides for its internal validation.

To be more precise, there's an XML file with just a namespace (no schema location or any other hints).
When validating, Oxygen processes that namespace through the catalog resolver (and the catalog file), determines the required schema (or uses the one specified in the validation scenario) and then invokes the validation engine with the detected/specified schema.
However, when using Saxon for transformation, the XML catalogs are simply passed on to Saxon and it uses its own catalog resolver mechanism that it seems is either:
- not aware of this namespace processing as URI or
- not configured properly by Oxygen to work this way
I've logged an issue to further investigate the problem and resolve it in a future version of Oxygen.

Currently, I'm afraid the only solution for this particular situation (no schema location) is to let Saxon use lax validation ("Validation of the source file:", "Lax schema validation"). Note that the same option is also present in the "Advanced options" (cogwheel icon button) of the Transformer engine from the transformation scenario editing dialog.

Regards,
Adrian