Bug #3638
closed
Child particle xs:invalidName
Category:
Schema-Aware processing
Applies to branch:
9.7, 9.8, trunk
Fix Committed on Branch:
9.7, 9.8, trunk
Fixed in Maintenance Release:
Description
Hi,
first of all, i hope that this is the right way to leave a bug Report.
We have a complex, schema aware xslt 3.0 script, based on XSD 1.0 Schema in two namespaces. Everthing was fine, until i changed the XSD Schema and introdiced an new type as an Extension of a complexType. The Schema seems to be valid, but the script complains about child particle xs:invalidName not found.
I have stepwise reduced the script as well as the schema. In the attached archive you will find three files. The script does not compile because of the error message given above. I'm working inside Oxygen IDE with Windows 10. It is Oxygen 19.1 bundled with Saxon 9.7.0.19.
Sincerely,
Frank
Files
- Status changed from New to In Progress
Progress so far:
Problem reproduced.
Saxon is type-checking the stylesheet and attempting to determine whether the axis expression descendant::s:customLevel is capable of selecting anything. To do this it searches the schema to get a list of all elements that can occur as descendants of an element with type rep:BaseReportType. During this analysis it establishes that there is a wildcard particle, and it indicates this by adding the pseudo element name xs:invalidName to the list of permitted descendants. For some reason (to be established) this then causes the observed error.
- Category set to Schema-Aware processing
- Assignee set to Michael Kay
At some stage, I think around 9.5, we changed this analysis to collect the set of allowed names as StructuredQName objects rather than integer fingerprints (this was part of an exercise to reduce compile-time contention on the NamePool). At this stage we switched from using -1 as the dummy value to using xs:invalidName. But UserComplexType.gatherAllPermittedDescendants contains the line if (contains(permittedChildren, -1)) which is clearly incorrect. Changing this to check for the StructuredQName xs:invalidName appears to do the trick.
Whether it was really wise to change this code to use StructuredQName objects instead of fingerprints is another question. The general aim at the time was to avoid using fingerprints except in code where it made a very real difference to performance; we were also trying to eliminate them entirely from use in schema components, with a view to making the representation of schema components independent of the NamePool and therefore transferable between Saxon Configurations. But this was never quite completed: element declarations in the schema do still have fingerprints, and so long as they do, it seems we might as well use them.
- Status changed from In Progress to Resolved
- Applies to branch 9.8, trunk added
- Fix Committed on Branch 9.8, trunk added
Fixed on the 9.8 branch and trunk. For the trunk, I have reverted to using integer fingerprints for these static analysis paths, rather than StructuredQName objects.
- Fix Committed on Branch 9.7 added
Also applied the patch to the 9.7 branch, just in case we ever produce another maintenance release for 9.7.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.8 added
Bug fix applied in the Saxon 9.8.0.8 maintenance release. Leave open until applied in the Saxon 9.7 release.
It seems this issue is not fixed in Oxygen 20 with Saxon 9.8.0.8 bundled
ID Système: /Users/innovimax/Downloads/child-particle-xsInvalidName/xsl/reporter.xsl
Fichier de validation principal: /Users/innovimax/Downloads/child-particle-xsInvalidName/xsl/reporter.xsl
Nom du scénario: XSLT
Type de document: XSLT
Nom du moteur: Saxon-EE 9.8.0.8
Gravité: error
Description: Child particle xs:invalidName not found
- Status changed from Resolved to In Progress
I haven't tried it from oXygen, but running from the command line, it fails under 9.8.0.7 and succeeds under 9.8.0.8.
I've installed oXygen 20 with Saxon 9.8.0.8 and now its failing. Strange! Unfortunately I don't have any way to debug Saxon when running under oXygen.
Something of a mystery. Although the Saxon JAR file issued with oXygen is not identical to the Saxonica version (because oXygen customize it for debugging support, etc), I've reverse-compiled their version and it definitely has this patch applied (class com.saxonica.ee.schema.UserComplexType, method getDescendantElementType).
We had a previous patch in for the UserComplexType class on our side for this issue:
https://saxonica.plan.io/issues/3478
and we forgot to remove the patch when we integrated Saxon 9.8.0.8.
We'll remove this patch from our side and have the fix available in a future Oxygen 20 minor bug fix release (probably in 2-3 weeks).
It looks fixed now on build XML Editor 20.0, build 2018042410
- Description updated (diff)
- Status changed from In Progress to Resolved
- Status changed from Resolved to Closed
Please register to edit this issue
Also available in: Atom
PDF
.