- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 03 May 2005 09:38:02 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1283
Summary: [XSLT/XQuery] Needless difference between XSLT and
XQuery in base URI handling
Product: XPath / XQuery / XSLT
Version: Last Call drafts
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: XQuery
AssignedTo: chamberl@almaden.ibm.com
ReportedBy: mike@saxonica.com
QAContact: public-qt-comments@w3.org
This is a coordination issue between XSLT and XQuery.
In XSLT, when an element is copied in the course of constructing its parent
element, the base URI of the child element is changed to be the same as its new
parent, unless it has an xml:base attribute that overrides this.
In XQuery, in the same circumstances, the base URI of the child element remains
unchanged.
I don't think there is any difference in requirements that justifies this
difference in behavior, so we should try to align the specs. I know that both
working groups consciously decided to write the specs the way they are - and
there are arguments for going either way - but I think we should have another
attempt to bring them into line.
The argument in favour of not changing the base URI is that this will tend to
preserve the meaning of any relative URIs in the content being copied.
The argument in favour of changing it is that a tree in which the base URI
changes arbitrarily from one element to another, without any visible signal such
as an xml:base attribute or an external entity reference, is very difficult for
users to understand. There are many other operations (such as serialization)
that cause the base URI to change, and if users want to protect themselves they
should either absolutize the URIs, or use xml:base. In fact there are many cases
where relative URIs are used quite deliberately because the base URI may vary.
There are arguments both ways, but there is no good reason for the two specs to
be inconsistent.
Received on Tuesday, 3 May 2005 09:38:09 UTC