Constructing namespace nodes

[G. Ken Holman]

XQuery doesn't have the same kind of instruction 
as the XSLT 2 <xsl:namespace> instruction, which 
adds a namespace node to the result tree and 
nothing else.  Your attempt to use the attribute 
keyword because a namespace node is not an attribute node.

An XQuery processor is obliged to not support the 
namespace axis, so you can't even create a 
temporary tree with namespace nodes and address 
them in order to copy them to the result 
tree.  This was a trick done with XSLT 1 and 
vendor extensions to create a result tree and then address its namespace axis.

I think you are out of luck to add only a 
namespace node and nothing else.  I think you 
have to add the bogus namespace-qualified 
attributes to your document element and in so 
doing end up with namespace nodes attached to that element.

I suggest you make your case to the W3C committee 
to convince them that the namespace axis and 
namespace nodes are first-class parts of the 
XPath model and should, therefore, be accessible 
in XQuery.  I haven't heard why XQuery explicitly 
chose to make the namespace axis unaccessible, 
rather than making it optional so that some 
XQuery engines could support it if they wanted to.

I hope this helps.

. . . . . . . . . Ken

At 2011-02-06 12:59 -0500, David Lee wrote:
>Content-Type: multipart/alternative;
>         boundary="----=_NextPart_000_0001_01CBC5FD.AA3BBAB0"
>Content-Language: en-us
>
>I am fairly sure I have answered my own 
>question, but I still can’t believe it.
>So maybe I’m missing something obvious.
>
>Using XQuery
>I need to create an XML file (in this case an 
>XSLT file) with namespaces declared in the root 
>node that are dynamically constructed.
>I’d *like* to do something like this (which doesn’t work 
)
>
><transform>
>    { for $n in $my_namespaces
>                 return attribute { 
> concat(“xmlns:” , $n/@prefix ) } { $n/@uri }
>     }
>

>
>In this case the list of namespaces needed is 
>*not* available as a static context in the XQuery.
>
>The best I’ve done so far is to create  bogus 
>attributes in a computed namespace.
>Actual code :
>
>
>document {
>     <xsl:stylesheet version="2.0" >
>     {
>         for $ns in $common:nsmap//ns
>         return
>             attribute { fn:QName($ns/@uri, concat($ns/@prefix,":bogus"))} {}
>
>     }
>
>
.
>}
>
>This creates a bunch of “bogus” attributes and 
>as a side effect also creates their namespace declarations.
>Like this:
>
><xsl:stylesheet  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 xmlns:ns1="http://www.w3.org/2001/XMLSchema"
>                 xmlns:ns2="http://www.xmlsh.org/jxml"
>                 version="2.0"
>                 ns1:bogus=""
>                 ns2:bogus="">
>
>
>The typical case I’ve seen documented is to 
>simply create the elements you need in the right 
>namespace then namespace nodes get created properly.
>This works fine *IF* you are creating elements 
>or attributes.  But in my case I am creating the dreaded QNames in Conent.
>e.g  XSLT Match expressions with prefixes 
 so 
>there are no actual elements or attributers with the namespaces.
>
>My question 
 is there a ‘better’ way of 
>creating apparently unused namespace nodes using XQuery based on runtime data ?
>
>Thanks for any suggestions.
>Fortunately this “hack” actually works with XSLT 
>as it ignores the bogus attributes 
 but if I 
>were having to do this for another document type it may not.
>


--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/q/
G. Ken Holman                 mailto:http://x-query.com/mailman/listinfo/talk
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal