Interesting. Just one thought (without think about
backward compatibility): an other solution would be to not
define the parent node for namespace nodes, as well as define
the identity testing being the same as value testing between
two namespace nodes. That would permit implementors more
freedom in the implementation of namespace nodes. Is it right?
Yes, at the time these decisions were being made this was one of the
proposals on the table. IIRC, one of the arguments against it was that XSLT
couldn't cope with "parentless" nodes - which of course it can now! Getting
rid of identity (the proposal was to have only one namespace node for a
(document, prefix, uri) triple, regardless where the namespace was declared)
has some odd side-effects such as x::child::node() being able to return
nodes that precede x in document order, and the more we looked at it the
messier it became.
Personally, I find if we must have namespaces at all, the original namespace
node model defined by James Clark works reasonably well. You just need to be
a bit creative in how you implement it - a naive implementation would
perform appallingly. One of the things I learnt from James was that when
someone argues against a specification on the grounds that it is impossible
to implement efficiently, they are usually wrong. (Sometimes that someone
was me...)
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--