Bug #3638: Child particle xs:invalidName - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3638

closed

Child particle xs:invalidName

Added by Frank Steimke almost 7 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Schema-Aware processing

Sprint/Milestone:

Start date:

2018-01-22

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7, 9.8, trunk

Fix Committed on Branch:

9.7, 9.8, trunk

Fixed in Maintenance Release:

9.8.0.8

Platforms:

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

child-particle-xsInvalidName.zip (2.2 KB) child-particle-xsInvalidName.zip

Frank Steimke, 2018-01-22 23:00

Actions

Copy link

Updated by Michael Kay almost 7 years ago

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.

Actions

Copy link

Updated by Michael Kay almost 7 years ago

Category set to Schema-Aware processing
Assignee set to Michael Kay

Actions

Copy link

Updated by Michael Kay almost 7 years ago

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.

Actions

Copy link

Updated by Michael Kay almost 7 years ago

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.

Actions

Copy link

Updated by Michael Kay almost 7 years ago

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.

Actions

Copy link

Updated by O'Neil Delpratt almost 7 years ago

% 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.

Actions

Copy link

Updated by xmlizer xmlizer over 6 years ago

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

Actions

Copy link

Updated by Michael Kay over 6 years ago

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.

Actions

Copy link

Updated by Michael Kay over 6 years ago

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.

Actions

Copy link

#10

Updated by Michael Kay over 6 years ago

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).

Actions

Copy link

#11