- 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