Bug #6198
closed
SCM export fails for a schema containing namespace prefixes in an XPath expression
0%
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.
Updated by Michael Kay 7 months 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).
Updated by Michael Kay 7 months 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.
Updated by Michael Kay 7 months 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.
Updated by Michael Kay 7 months ago
- Status changed from In Progress to Resolved
- Fix Committed on Branch 11, 12, trunk added
Updated by O'Neil Delpratt 5 months ago
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 Maintenance release. Leaving it marked as 'Resolved' until fix applied on Saxon 11.
Please register to edit this issue
.