Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #3066

closed

Specialist name() treatment of XHTML elements

Added by John Lumley almost 8 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Debbie Lockett
Category:
-
Sprint/Milestone:
-
Start date:
2016-12-12
Due date:
% Done:

0%

Estimated time:
Applies to JS Branch:
0.9
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Platforms:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

DomUtils.nameoOfNode() treats elements in the namespace http://www.w3.org/1999/xhtml as a special case - returning a QName with a blank (@""@) URI. This of course has the advantage that within normal SaxonJS operation XPath expressions automatically apply to either HTML or XHTML elements in the document.

There are however some consequences of this:

  1. Using a namespace prefix bound to http://www.w3.org/1999/xhtml within an XPath expression doesn't match elements within that namespace, as their name() is returned in the "" uri namespace, but this is checked against @http://www.w3.org/1999/xhtml@.

  2. Setting the xpath-default-namespace="http://www.w3.org/1999/xhtml" has similar effect - no elements in that namespace are now retrieved from unprefixed names in an XPath expression

In cases where the XPath expression is dynamic, such as in xsl:evaluate or in the forthcoming XPath API, this becomes more complicated as it is still not possible to select XHTML elements via a bound prefix.

Actions
Copy link
 #1

Updated by Michael Kay almost 8 years ago

I think this is by design, and I'm not sure what you are suggesting we should do differently. Essentially we've made a decision that in our XDM representation of the HTML DOM, HTML elements should be treated as no-namespace elements. We could have chosen to treat them as being in the XHTML namespace, but that would have made most queries more difficult. I don't think other solutions such as matching them in either namespace would help.

Actions
Copy link
 #2

Updated by John Lumley almost 8 years ago

  • Status changed from New to Resolved

Understood..... and this should only apply to HTML DOM traversal, not XML. Perhaps worth putting a note in the documentation (http://www.saxonica.com/saxon-js/documentation/index.html#!development/source-documents - first bullet point) that a consequence is that prefixes or xpath-default-namespace bound to XHTML will therefore be inoperative on such documents.

Actions
Copy link
 #3

Updated by Debbie Lockett over 7 years ago

  • Status changed from Resolved to Rejected
  • Applies to JS Branch 0.9 added

Changing status to "Rejected" since there was no code bug. (The issue was previously left "unclosed" as a reminder to add the documentation note.)

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF Tracking page