Project

Profile

Help

Bug #3638

closed

Child particle xs:invalidName

Added by Frank Steimke about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
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:
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 #1

Updated by Michael Kay about 6 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 #2

Updated by Michael Kay about 6 years ago

  • Category set to Schema-Aware processing
  • Assignee set to Michael Kay
Actions #3

Updated by Michael Kay about 6 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 #4

Updated by Michael Kay about 6 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 #5

Updated by Michael Kay about 6 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 #6

Updated by O'Neil Delpratt about 6 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 #7

Updated by xmlizer xmlizer about 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 #8

Updated by Michael Kay about 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 #9

Updated by Michael Kay about 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 #10

Updated by Michael Kay about 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 #11

Updated by Octavian Nadolu about 6 years ago

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

Actions #12

Updated by xmlizer xmlizer almost 6 years ago

It looks fixed now on build XML Editor 20.0, build 2018042410

Actions #13

Updated by Michael Kay over 5 years ago

  • Description updated (diff)
  • Status changed from In Progress to Resolved

Marking as resolved.

Actions #14

Updated by O'Neil Delpratt over 5 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF