Bug #2632
closed
Type checking of patterns assumes context item is a node
Category:
XSLT conformance
Fix Committed on Branch:
9.7
Fixed in Maintenance Release:
Description
In typeCheck(String name, Pattern pattern), the code assumes that the context item type will be a node.
This is causing a failure in HE (reported by Martin Honnen on the support email address) in a match pattern that matches arrays. It's not clear why such a basic error in the code, on a widely used path, should have such limited symptoms; in particular, why it should fail in HE and not in EE.
- Status changed from New to In Progress
For some reason in Saxon-HE the pattern .[. instance of array(..)] is being compiled as a PatternWithPredicate under HE, but as a BooleanExpressionPattern under EE. The BooleanExpressionPattern code is setting the context item type for the predicate to item(), but the code for PatternWithPredicate is leaving it at node().
The class BooleanExpressionPattern exists in HE but it is never used (the only call to new BEP() is within its own copy() method). In EE the BooleanExpressionPattern is instantiated from PatternParser30 which is specific to PE and EE.
We decided with 9.7 that we would support XPath 3.0 in Saxon-HE (because it's at Rec status) but we wouldn't support XSLT 3.0 (because it isn't). Then we decided that if we were supporting XPath 3.0 in HE, it didn't really make much sense (and wasn't easy anyway) to prevent use of XPath 3.0 within XSLT 3.0. Then XPath 3.1 came along, which isn't yet at Rec, but it only complicates the software to disallow XP 3.1 while allowing XP 3.0, so the whole situation all gets muddled. Hopefully the final recommendations and conformance rules will soon be finalised, and we can then simplify things. (One of the motivations for the current state of affairs is that until there is a 3.0 recommendation, we want to provide a product that has strict conformance to 2.0, which means rejecting 3.0 constructs. Once 3.0 is final, we can drop conformance to 2.0, and thus drop the code that treats 3.0 facilities as optional.)
Given this policy, we ought to disallow the pattern match=".[. instance of XXX]" in Saxon-HE, on the grounds that this isn't a valid XSLT 2.0 pattern. The problem arises because we are allowing the syntax, but don't have full support for the semantics.
The code for type-checking patterns against node() also needs to be fixed.
- Status changed from In Progress to Resolved
- Fix Committed on Branch 9.7 added
I have committed two patches on the 9.7 branch.
(a) In StyleElement.typeCheck(String, Pattern), the context item type is now set to node() if running as a 2.0 processor, or item() if running as a 3.0 processor, reflecting the fact that patterns can now match any kind of item.
(b) In PatternParser20, which is used in Saxon-HE or when running as a 2.0 processor, the token "." is now disallowed outside a predicate.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.4 added
Bug fix applied in the Saxon 9.7.0.4 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF
.