Project

Profile

Help

Bug #4197

closed

Default namespace for QNames in xsl:catch

Added by Michael Kay about 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2019-04-13
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:
Platforms:

Description

If an unprefixed name appears in the list of NameTests in xsl:catch, Saxon is using the value of xpath-default-namespace (the default namespace for elements and types). Is this right?

Actions #1

Updated by Michael Kay about 5 years ago

I think XSLT 3.1 ยง5.1.2 (on xpath-default-namespace) suggests that the xpath-default-namespace attribute should NOT apply to NameTests appearing in xsl:catch. The general tone of this section is that it enumerates the places where xpath-default-namespace takes effect, and that "other names" than those listed are not affected.

Actions #2

Updated by Michael Kay about 5 years ago

Looking at this further, I think the handling of unprefixed names in element-available() might also be wrong. The rules for element-available() say "If there is a default namespace in scope, then it is used to expand an unprefixed lexical QName." It's not 100% clear what this means.

Actions #3

Updated by Michael Kay about 5 years ago

  • Category set to XSLT conformance
  • Status changed from New to Resolved
  • Priority changed from Low to Normal
  • Applies to branch 9.9, trunk added
  • Fix Committed on Branch 9.9, trunk added

Added xslt-30 test cases try-036 and try-037; confirmed that these were failing.

Fixed by a simple one-liner patch in XSLCatch.

Actions #4

Updated by O'Neil Delpratt almost 5 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.9.1.3 added

Bug fix applied to the Saxon 9.9.1.3 maintenance release

Please register to edit this issue

Also available in: Atom PDF