- 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