Bug #5647
closed
"String constructors" and character escaping in XQuery?
Category:
XQuery conformance
Applies to branch:
10, 11, trunk
Fix Committed on Branch:
10, 11, trunk
Fixed in Maintenance Release:
Description
According to the XQuery spec,
Character entities are not expanded in string constructor content. Thus, [<]
evaluates to the string "<", not the string "<".
So I think one would expect this query:
``[good & bad]``
=> parse-xml-fragment()
to return good & bad
. But SaxonJ claims the input is not well formed because, I think, the "&" has been expanded.
I've not previously encountered "string constructors" before, so I'm not sure.
I've added test cases prod-StringConstructor-029
and -030
.
Yes, there seems to be a bug here.
StringConstructors seem to be very rarely used - the syntax is far too unmemorable. Mind you, one could say that of CDATA sections as well: but perhaps the payoff for using CDATA is higher.
The analysis of stringConstructors is rather clumsily split between the tokenizer and parser, and there are separate paths for a StringConstructor with enclosed expressions and one without - we need to test both.
In the current test case, without enclosed expressions, the tokenizer is returning a STRING_LITERAL_BACKTICKED
and (at XPathParser#2552) we are processing this in exactly the same way as a STRING_LITERAL
, which means that unescaping is applied.
The situation appears to be as follows.
-
If there are no enclosed expressions, then the <
is incorrectly unescaped as <
.
-
If there is one enclosed expression, then the result is correct.
I haven't tried to work out what happens if there is more than one enclosed expression!
- Category set to XQuery conformance
- Status changed from New to Resolved
- Applies to branch 11, trunk added
- Fix Committed on Branch 11, trunk added
- Platforms .NET, Java added
- Applies to branch 10 added
- Fix Committed on Branch 10 added
Retrofitted the patch to the 10.x branch.
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.0 added
Bug issue fix applied in the Saxon 12.0 Major Release.
Leaving this bug marked as Resolved until fix applied
- Fixed in Maintenance Release 11.5 added
Bug fix applied in the Saxon 11.5 maintenance release.
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 10.9 added
Bug fix applied in the Saxon 10.9 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF