- From: Per Bothner <per@bothner.com>
- Date: Mon, 24 Nov 2003 23:00:38 -0800
- To: public-qt-comments@w3.org
The semantics of computed namespace constructors is unclear: 3.7.3.7 Computed Namespace Constructors A constructed namespace node ... binds a namespace prefix represented as NCName in the syntax) to a URI and adds the namespace prefix to the in-scope namespaces for its enclosing element. But the "in-scope namespaces" is part of the *static* context, and constains both prefix *and* URIs: [Definition: In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.] So how can a run-time namespace expression add to the static in-space namespaces? It might be possible to change the sementics so only the namespace prefixes is part of the static context, while the namespace uri is part of the dynamic context, but that would certainly complicate implementation and probably the semantics Consider: element {$ename} { namespace xx { myns:f($myns:x) }, namespace myns {if $version eq 1 then "http://example.org/v1" else "http://example.org/v2"}, attribute xx:type {"myns:invoice"}, $content } This has a forward reference to the myns namespace (is that allowed?), and an function name, a variable name, and an attribute name, all of whose namespaces have to be calculated at run-time. I assume the intention is to not allow that. I suggest a separate concept of "active namespaces" consisting of anmespaces declared in namespace attributes and namespace constructors. This could be part of the dynamic environment, but not the static environment. -- --Per Bothner per@bothner.com http://per.bothner.com/
Received on Tuesday, 25 November 2003 02:00:35 UTC