- From: Michael Kay <mike@saxonica.com>
- Date: Tue, 2 Jun 2009 13:51:54 +0100
- To: 'Krzysztof Maczyński' <1981km@gmail.com>, <public-qt-comments@w3.org>
Personal response:
You can do this with a computed element constructor (or attribute
constructor):
element {QName($namespace, $local)}{ "content" }
It was never intended that namespaces in a namespace declaration attribute
should be computable by including enclosed expressions: this wouldn't work,
because such declarations as well as causing namespaces to be added to the
constructed node at run-time, also cause namespaces to be added to the
static context, which means they must be statically known. This is why the
existing (pre-erratum) text in 3.7.1.2 says "The value of a namespace
declaration attribute must be a URILiteral; otherwise a static error is
raised [err:XQST0022].". The purpose of the erratum was to reconcile this
with the BNF productions, which indicate that doubled curly-braces and
quotation marks are recognized.
Michael Kay
Saxonica
> -----Original Message-----
> From: public-qt-comments-request@w3.org
> [mailto:public-qt-comments-request@w3.org] On Behalf Of
> Krzysztof Maczynski
> Sent: 02 June 2009 13:01
> To: public-qt-comments@w3.org
> Subject: XQ.E13 - how to construct a node in a namespace with
> computed name?
>
> Dear WG,
>
> I know I'm writing a bit past the PER review period, but for
> the last few days I've been deprived of Internet access -
> hope your internal process still allows doing something
> meaningful with my input. Having read the erratum XQ.E13 for
> XQuery 1.0 I'm wondering how I should proceed in order to
> construct an element or attribute in a namespace whose name
> is to result from an expression instead of being given
> literally as a URI. Is this being made intentionally
> impossible? If so, why? If not, what's the workaround and why
> should we be forced to use it?
>
Received on Tuesday, 2 June 2009 12:52:33 UTC