Bug #6198: SCM export fails for a schema containing namespace prefixes in an XPath expression - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #6198

closed

SCM export fails for a schema containing namespace prefixes in an XPath expression

Added by Michael Kay over 1 year ago. Updated about 1 year ago.

Status:

Resolved

Priority:

Normal

Assignee:

Michael Kay

Category:

Sprint/Milestone:

Start date:

2023-09-17

Due date:

% Done:

Estimated time:

Legacy ID:

Applies to branch:

11, 12, trunk

Fix Committed on Branch:

11, 12, trunk

Fixed in Maintenance Release:

12.4

Platforms:

.NET, Java

Description

Export of a schema containing <xs:selector xpath="s:person"/> succeeds, but the schema cannot be re-imported from the resulting SCM file; it fails saying that the namespace prefix s has not been declared.

The problem appears to be that SchemaModelSerializer.emitNamepaceContext does not actually emit anything to the SCM file.

History
Notes
Property changes

Actions

Copy link

Updated by Michael Kay over 1 year ago

Status changed from New to In Progress
Priority changed from Low to Normal
Applies to branch 11, 12, trunk added
Platforms .NET, Java added

This one is fairly complex.

There are two main problems: firstly, we aren't writing the namespaces out to the SEF file, and secondly, if we do that, the mechanism to read them back in again isn't working properly.

I think this wasn't working in Saxon 10 (ever since the big changes to namespace representation with the intrduction of the NamespaceMap). So I don't think there's an imperative requirement to fix it in a way that's compatible with the SCM files from earlier releases. I would rather output in-scope namespaces in the same way as we do within SEF files. But that (a) involves some refactoring of code to make it reusable, and (b) involves a change to the schema for SCM files.

The basic change is that for the various schema components that include XPath expressions (assertion, alternative, selector, field), we should output an additional attribute containing the namespace bindings in the condensed microsyntax used for SEF files; and when loading SCM files, of course, we read this attribute and set the relevant namespaces in the XPath static context.

While testing this I discovered that the scmschema.scm file in the samples/scm directory needs to be updated with a refreshed license key (it's built with a facility not available to ordinary users whereby the license key is embedded in the compiled schema, allowing it to be used for validation without purchasing a separate license).

Actions

Copy link

Updated by Michael Kay over 1 year ago

Further testing reveals another place where the problem occurs: when the schema involves an enumeration facet whose values are QNames. Schema test case -c:NIST -s:NIST2004-01-14 -g:list-QName-enumeration

In this test case we are in fact outputting the namespace bindings in the form of real XML namespaces in the SCM file; but we appear to be failing to read them back. We're relying on the NamespaceReducer filter in the pipeline to maintain the current set of namespace bindings, and it is failing to do so. SchemaModelLoader line 1114 attempts to set the namespace context on the enumeration facet by retrieving it from the NamespaceReducer, but the NamespaceReducer seems to no longer maintain it. Which is because, since the introduction of NamespaceMaps on the startElement() call, this functionality really isn't needed any more, so a lot of the code that maintained it is now defunct.

The solution turns out to be easy, we now have the full namespace context on the startElement() event, so laboriously reconstructing it in the NamespaceReducer is totally unnecessary.

Actions

Copy link

Updated by Michael Kay over 1 year ago

I decided to remove the NamespaceReducer from the pipeline and 8 out of 41545 tests failed as a result! The tests are:

   <test set="suntest" group="test003a" name="test.2.n"/>
   <test set="suntest" group="test003a" name="test.3.n"/>
   <test set="suntest" group="test003a" name="test.4.n"/>
   <test set="suntest" group="test003a" name="test.5.n"/>
   <test set="suntest" group="test003b" name="test.2.n"/>
   <test set="suntest" group="test003b" name="test.3.n"/>
   <test set="suntest" group="test003b" name="test.4.n"/>
   <test set="suntest" group="test003b" name="test.5.n"/>

But these are the tests that I added recently in response to bug #6153.

These are failing with or without the -scm option so I'll reopen #6153.

Actions

Copy link