This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In XQuery: http://www.w3.org/TR/xquery/#id-base-uri-decl "It is not intrinsically an error if this process fails to establish an absolute base URI; however, the base URI in the static context is then undefined, and any attempt to use its value may result in an error [err:XPST0001]." Suppose that we fail to establish an absolute base URI. Therefore the base URI in the static context is undefined. Consider how we might access this undefined value (to raise err:XPST0001). 1. fn:static-base-uri http://www.w3.org/TR/xquery-operators/#func-static-base-uri "If the Base URI property is undefined, the empty sequence is returned" 2. document node construction http://www.w3.org/TR/xquery/#id-documentConstructors "base-uri is taken from base URI in the static context. If no base URI is defined in the static context, the base-uri property is empty." 3. element node construction http://www.w3.org/TR/xquery/#id-content "Otherwise, the value of the base URI in the static context." From my reading of the above, only (3) can cause XPST0001 to be raised since (1) and (2) both explicitly state how to handle the case where the static context base URI is undefined. Is this intentional? The difference between document and element node construction is particularly surprising.
A further way to access the static context base URI is: 4. fn:resolve-uri http://www.w3.org/TR/xquery-operators/#func-resolve-uri "If the base-uri property is not initialized in the static context an error is raised [err:FONS0005]."
By far the most common use of the static base URI in practice is to resolve relative URIs passed to the doc() function. This will fail if no static base URI has been established.
Good point. Would you agree that it might make more sense if element node constructors were to follow the same logic as document nodes? i.e. "base-uri is taken from base URI in the static context. If no base URI is defined in the static context, the base-uri property is empty."
I can't be certain, but I suspect the intended meaning for element constructors was the same as for document constructors: the base URI of the element is the same as the base URI in the static context, which means it's null/absent/empty/undefined/none if the value in the context is null/absent/empty/undefined/none. (I wish I understood which of these terms we should use...) One could argue that this code isn't "using" the value of the static base URI, it's only copying it... It could probably be clarified, except that when you go near base URI, something always breaks.
(Action ACTION A-344-03) As expected, the more you dig into this the deeper the hole you find yourself in. Firstly, I think that XDM should make it more clear that the base URI of a node may be unknown. In practice this is common, it happens whenever you parse an XML document supplied as a string in memory. The possibility is also recognized (more or less) in the Infoset. This seems to require changing (or clarifying the meaning of) section 6.1.3 where it says "The following infoset properties are required: [children] and [base URI].". XDM allows the base-uri() accessor to return (), and we should make it clear that this is what happens when the base URI property of a node is unknown. Secondly, XQuery needs to make it clear (as suggested in the bug report) that for element nodes as well as document nodes, if the static base URI is unknown then the base URI of the constructed node will be unknown. (I think "unknown" is a better term here than "empty", which is the term used for document node constructors. In fact, there are many, many places in XQuery and XSLT where the base URI of one thing is taken from the base URI of another. We really don't want to change all these places to say explicitly that if the first base URI is unknown then the second base URI will also be unknown. I think it would be best to say it once, and a good place seems to be XQuery 4.5. Change: "It is not intrinsically an error if this process fails to establish an absolute base URI; however, the base URI in the static context is then undefined, and any attempt to use its value may result in an error [err:XPST0001]." to "It is not intrinsically an error if this process fails to establish an absolute base URI; however, the base URI in the static context is then undefined. When the base URI in the static context is undefined, any attempt to use its value to resolve a relative URI reference will result in an error [err:XPST0001]. When the base URI of a constructed node is taken from the base URI in the static context and the latter is undefined, then the base URI of the node will be unknown." This makes the current sentence in 3.7.3.3. 4(a) redundant. I've looked through XSLT to see whether the same changes need to be made there. Frankly, I don't think it's necessary. There are many places where the base URIs are copied from one place to another and I think it's reasonable for readers to infer that if the source base URI is unknown/undefined then the target base URI will be unknown/undefined.
This bug was discussed by the working groups on 8 Jan 2008. The working groups agreed to amend the final paragraph of XQuery Section 4.5 (Base URI Declaration) as suggested by Michael Kay in comment #5. This bug report remains open pending possible additional changes to the Data Model specification. --Don Chamberlin (for the XQuery and XSLT working groups)
Anders has stated that he believes no change is needed to the XDM specification. I'm not comfortable with this. In 6.1.1 and 6.2.1 we say "base URI, possibly empty" which is fine. But in 6.1.3 (construction from an Infoset) we say: The following infoset properties are required: [children] and [base URI]. The following infoset properties are optional: [unparsed entities]. with similar text in 6.2.3 and 6.5.3 This gives the strong impression that when creating an XDM document from an InfoSet, there must be a base URI, and I don't think this is the case. I don't think it's good enough to argue that "required" leaves open the possibility of the value existing but being empty; if we want to make that kind of subtle distinction then we need to be a lot more formal. The Infoset spec does not explicitly discuss that the [Base URI] property can be absent or unknown, but it is clearly something that can happen in practice. I think XDM should make it clear, in discussing construction from an Infoset in the sections cited, that if the infoset [Base URI] property value is absent or unknown (these are the terms Infoset uses) then the XDM property will be empty.
Proposed change to XDM: 6.1.3. [I'm not entirely sure what the spec is trying to say when it says that some InfoSet properties are required and others are optional. Is it a statement about the InfoSet, or about the process of construction from an InfoSet?] Change <old> The following infoset properties are required: [children] and [base URI]. The following infoset properties are optional: [unparsed entities]. </old> to <new> The following infoset properties are used: [children], [base URI], and [unparsed entities]. </new> Under "base URI" change <old> The value of the [base URI] property. Note that the base URI property is always an absolute URI (if an absolute URI can be computed) though it may contain Unicode characters that are not allowed in URIs. These characters, if they occur, are present in the base-uri property and will have to be encoded and escaped by the application to obtain a URI suitable for retrieval, if retrieval is required. </old> to <new> The value of the [base URI] property, if available. Note that the base URI property, if available, is always an absolute URI (if an absolute URI can be computed) though it may contain Unicode characters that are not allowed in URIs. These characters, if they occur, are present in the base-uri property and will have to be encoded and escaped by the application to obtain a URI suitable for retrieval, if retrieval is required. In practice a [base URI] is not always known. In this case the value of the <b>base-uri</b> property of the document node will be the empty sequence. This is not intrinsically an error, though it may cause some operations that depend on the base URI to fail. </new> 6.2.3: Make the corresponding changes 6.5.3: Make the corresponding changes
Extract from the minutes of telcon 358: >J3.1.1 Bugzilla Bug 5207, [XQuery] Accessing >undefined static context base URI and XPST0001 >http://www.w3.org/Bugs/Public/show_bug.cgi?id=5207 > >Status: READY FOR DISCUSSION >See http://www.w3.org/Bugs/Public/show_bug.cgi?id=5207#c8 Mike Kays proposal in c8 discussed. Decided to accept adding "if available" in first paragaraph. Also retain the "In practice..." paragraph. Changing "required" to "used" was rejected.