- From: Jonathan Robie <jwrobie@mindspring.com>
- Date: Thu, 12 Feb 2004 12:22:34 -0500
- To: Michael Kay <mhk@mhk.me.uk>
- Cc: 'Don Chamberlin' <chamberl@almaden.ibm.com>, public-qt-comments@w3.org
Then perhaps the XSLT spec can describe things in terms of namespace nodes - these are equivalent descriptions, and the XSLT spec could describe how to map between them. All of our documents currently use both the "in-scope" model Don suggests and the namespace node model - if we can limit this flaw to just the XSLT document, that's still a win. Jonathan > Unfortunately, making this change would require an enormous upset in > the way the XSLT semantics are described (where explicit construction > of namespace nodes is very much part of the model, and is needed > because we allow dynamic construction of namespaces). > > Michael Kay > > -----Original Message----- > *From:* public-qt-comments-request@w3.org > [mailto:public-qt-comments-request@w3.org] *On Behalf Of *Don > Chamberlin > *Sent:* 11 February 2004 23:25 > *To:* public-qt-comments@w3.org > *Subject:* [DM] IBM-DM-031: No need for namespace nodes > > > (IBM-DM-031) The Data Model document lists namespace nodes as one > of the seven kinds of node. But a node is needed only to preserve > identity and to represent a position on an axis. The identity of a > namespace node is never used, and the namespace axis is deprecated > in XPath 2.0 and not supported in XQuery. Neither XPath nor XQuery > provides a way to construct a namespace node independently of an > element node. Therefore there is no reason to retain the concept > of a namespace node in XPath 2.0. It should be replaced by the > concept of "in-scope namespaces" as a property of an element node. > The term "in-scope namespaces" is already widely used (13 times in > the Data Model document and 10 times in the Functions and > Operators document). We should make "in-scope namespaces" one of > the properties of an element node, supported by two accessors > (get-namespace-uri-for-prefix() and get-in-scope-prefixes(), which > are already documented in Functions and Operators). We should > leave it up to the implementation how to support these accessors. > Various strategies are possible, including storing all the > in-scope prefixes in each element node, or only storing the "new" > prefixes that are introduced by each node (different from its > parent). > > Replacing namespace nodes with the existing concept of "in-scope > namespaces" will shorten and simplify the Data Model document, > removing various accessors on namespace nodes which XQuery does > not provide any way to invoke. Implementations that choose to > support the (deprecated) namespace axis can synthesize "namespace > nodes" from the "in-scope namespaces" property of an element node. > Implementations that do not support this deprecated axis need not > be aware of namespace nodes at all. All references to "namespace > nodes" in XPath and XQuery-related documents (such as the > Serialization document) can be rephrased in terms of the more > abstract concept of "in-scope namespaces" for an element; this > provides greater implementation flexibility and in many cases > simplifies the documents. > > --Don Chamberlin >
Received on Thursday, 12 February 2004 12:25:07 UTC