Saxon

Legacy ID: #4804490 Legacy Poster: Michael Kay (mhkay)

What's wrong with "declare default element namespace" in the XQuery prolog (or the equivalent issued from the Java API)? I'm not actually sure you are doing users a favour with this. It's hard enough to understand how namespaces work in the W3C specifications without understanding a customization added locally and not described in any textbooks or tutorials.

Legacy ID: #4804706 Legacy Poster: Chapman Flack (jcflack)

If there were such a thing as a scoped "default namespace expression" rather than a single "declare default element namespace" in the prolog, I'd be really happy. I understand this is a language design issue rather than a Saxon issue. But since you asked, think about what has to be a common type of query: I pull down 5 source documents from 5 URLs, which are of 5 different document types in 5 different namespaces; I apply a bunch of nontrivial XPath expressions to these sources to pull out interesting bits and pieces and join them together, producing a result document in a 6th distinct namespace. The ability to declare a single default element namespace doesn't offer much in that context. At best you can pick one of the namespaces that you'll have to deal with and declare it as default, which will simplify the part of your query that deals predominantly with that namespace, without helping anywhere else. It might also add confusion if one of the source documents is non-namespaced so you also have to write XPath expressions that refer to things with no namespace. There sanity dictates declaring all of the namespaces you need with nonempty prefixes. Which. You. Have. To. Repeat. In. Every. Step. Of. An. XPath (or forget, and produce an expression that compiles without error and matches nothing). let $foo := $bar/dsml:searchResponse[@id eq 'a']/dsml:field[@name eq 'x']/dsml:value let $baz := $quux/fm:record[fm:field[@name eq 'x']/fm:value eq $foo] /fm:field[@name eq 'y']/fm:value return <html:tr><html:td>{$foo}</html:td><html:td>{$baz}</html:td></html:tr> By conventional language design principles, all those repeated prefixes are redundant noise; the programmer wants to write a concise description of the task, not to compete for a typing award. let $foo := default dsml { $bar/searchResponse[@id eq 'a']/field[@name eq 'x']/value } let $baz := default fm { $quux/record[field[@name eq 'x']/value eq $foo] /field[@name eq 'y']/value } return default html { <tr><td>{$foo}</td><td>{$baz}</td></tr> } where my imaginary "default expression" takes the prefix of an already declared namespace and makes the default within a scope refer to the same namespace. Only in the last line can I accomplish anything reasonably similar, by writing: return <tr xmlns='http://www.w3.org/1999/xhtml'&gt;&lt;td&gt;{$foo}&lt;/td&gt;&lt;td&gt;{$baz}&lt;/td&gt;&lt;/tr> but that can't be done by referring to the already-declared prefix, it requires repeating the full URI in place; that goes against the other usual programming guideline that you avoid scattering long fiddly constants through code, but declare them in one place then use the declared names, which the compiler can warn you about if your spelling falters. Obviously my "default expression" won't ever be in XQuery unless it gets proposed to the right people and incorporated in some later version, so I was just trying to find a way to accomplish anything similar in the short term. Chapman Flack

Legacy ID: #4804742 Legacy Poster: Michael Kay (mhkay)

I think it's generally true in XQuery for most aspects of the static context that it would be nice to be able to control them at a finer-grained level. XSLT achieves this by use of attributes that can be used on any instruction in the stylesheet. Because XQuery isn't XML it's harder to invent such mechanisms. Generally if you're handling multiple namespaces in XQuery (and indeed in XSLT) I think it's probably best to prefix every name rather than using defaults. In the long run, it's clearer. But I'm afraid discussing the issue here will not achieve much - it's a language design issue.