This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[This may be related to Bug ID 4463.] There appears to be a namespace usability problem in XQuery 1.0: when the source document is in no namespace and you need the result elements to be in a default (unprefixed) namespace. My use case is KML, the markup for Google Earth [see http://code.google.com/apis/kml/documentation/kml_tut.html ] Ive having difficulty outputting the correct default namespace from a query. [I'm using SaxonB 8.9J on Windows XP with jre 1.6.0_01.] With this trivial input: <?xml version="1.0" encoding="UTF-8"?> <bar>foobar</bar> and trivial XQuery #1: <kml> <Folder> { for $i in doc("namespace.xml")//bar return $i } </Folder> </kml> I get the result #1: <?xml version="1.0" encoding="UTF-8"?> <kml> <Folder> <bar>foobar</bar> </Folder> </kml> However, I need the opening <kml> to appear as: <kml xmlns="http://earth.google.com/kml/2.1"> With XQuery #2: <kml xmlns="http://earth.google.com/kml/2.1"> <Folder> { for $i in doc("namespace.xml")//bar return $i } </Folder> </kml> I get result #2: <?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://earth.google.com/kml/2.1"> <Folder/> </kml> Which isn't correct for the <Folder> content. I've also tried adding a default namespace declaration to XQuery #2: declare default element namespace "http://earth.google.com/kml/2.1"; but that has no impact; I still get result #2. Unfortunately, Google Earth really seems to expect an unprefixed default namespace. When I take their basic examples and add a prefix, like so: <?xml version="1.0" encoding="UTF-8"?> <ge:kml xmlns:ge="http://earth.google.com/kml/2.1"> <ge:Folder> <ge:Placemark> <ge:name>Simple placemark</ge:name> <ge:description>Attached to the ground. Intelligently places itself at the height of the underlying terrain. </ge:description> <ge:Point> <ge:coordinates>-122.0822035425683,37.42228990140251,0</ge:coordinates> </ge:Point> </ge:Placemark> </ge:Folder> </ge:kml> Google Earth thinks the root <kml> element is "bad or missing". Therefore, my use case is problematic with XQuery 1.0, as far as I understand. The workaround is to simply output "<kml>" with no namespace attribute, which Google Earth appears to understand, although the usability issue remains for XQuery.
I agree that there's a usability problem here. Sometimes you do need to generate output in a default namespace, for example because there's a DTD that requires this for validity, or because there's some other bit of software at the receiving end that isn't 100% namespace-aware. I think we should put this use case on the requirements list for XQuery 1.1. Personally I think the right answer is along the lines we adopted in XSLT 2.0: allow a different default namespace for element names in path expressions and element names in constructors.
Perhaps I'm not understanding your issue. I would expect the following query: <kml xmlns="http://earth.google.com/kml/2.1"> <Folder> { for $i in doc("namespace.xml")//*:bar[namespace-uri()=''] return $i } </Folder> </kml> to return the following result: <?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://earth.google.com/kml/2.1"> <Folder> <bar xmlns="">foobar</bar> </Folder> </kml> Does this meet your needs?
From a usability point of view, I don't think you can expect people writing 1000-line queries to use the construct *:bar[namespace-uri()=''] every time they want to refer to an element name in the source document. I can think of a number of possible solutions: (a) following XSLT 2.0, introduce a prolog declaration declare default path namespace "zzzz"; indicating that an unprefixed element name in a Step is considered to be in namespace "zzzz", regardless of any other default namespace that might be in force (b) introduce syntax that allows one to refer to an element in no namespace as distinct from an element in the default namespace, for example :foo or ~:foo (c) introduce some capability to set the namespace context locally without constructing a new element, for example with xmlns="" { foo/bar }
(In reply to comment #2) > Does this meet your needs? > It gets the right answer but in general rewriting a large set of queries from /a/b[c=d]/e to /*:a[namespace-uri()='']/ *:b[namespace-uri()=''][*:c[namespace-uri()='']=*:d[namespace-uri()='']]/ *:e[namespace-uri()=''] is tedious and error prone, and the resulting expression is definitely harder to read and maintain. Also the resulting expression may fail on systems using static typing checks as (I think) that by using /*:bar[namespace-uri()=''] form you would fail to match an expected type that required a sequence of bar elements in no-namespace as the static typing won't see inside the predicate and so type this as a sequence of elements in any namespace. David
(In reply to comment #3) I agree that usability is the main problem from my user viewpoint. Of the potential solutions that Michael has offered below, I am most partial to option (a) and secondarily to (b). For my needs, it would most useful if the scope is the entire XQuery, as in option (a), but I can imagine how in other use cases it may be desirable to switch the default namespace, such as in a specialized local function, which makes option (b) or (c) appealing. > From a usability point of view, I don't think you can expect people writing > 1000-line queries to use the construct > > *:bar[namespace-uri()=''] > > every time they want to refer to an element name in the source document. > > I can think of a number of possible solutions: > > (a) following XSLT 2.0, introduce a prolog declaration > > declare default path namespace "zzzz"; > > indicating that an unprefixed element name in a Step is considered to be in > namespace "zzzz", regardless of any other default namespace that might be in > force > > (b) introduce syntax that allows one to refer to an element in no namespace as > distinct from an element in the default namespace, for example :foo or ~:foo > > (c) introduce some capability to set the namespace context locally without > constructing a new element, for example > > with xmlns="" { > foo/bar > } >
The XML Query and XSL WGs discussed this at our June 27 meeting. Several members expressed sympathy with the usability problem that you have raised. We did not, however, feel that we can address this as an errata to XQuery 1.0. We have decided to consider this as an enhancement request for XQuery 1.1. As such, I have changed the severity of the bug report to "enhancement" and the resolution to "LATER". Please close this bug report if you agree with this resolution.
(In reply to comment #6) > The XML Query and XSL WGs discussed this at our June 27 meeting. Several > members expressed sympathy with the usability problem that you have raised. We > did not, however, feel that we can address this as an errata to XQuery 1.0. > > We have decided to consider this as an enhancement request for XQuery 1.1. As > such, I have changed the severity of the bug report to "enhancement" and the > resolution to "LATER". > > Please close this bug report if you agree with this resolution. > Is there a ballpark timeframe for XQuery 1.1? (I have closed the bug report as requested.) -Ken Sall, SAIC
>Is there a ballpark timeframe for XQuery 1.1? I think W3C WGs tend not to publish their target dates, largely because they rarely achieve them. There's a good reason for that, which is that a standards development effort doesn't have a resourced plan - you can't control what topics and issues are going to be raised by members or the general public, and you can't predict how much time WG members are going to devote to dealing with them.