Expanding QNames in ElementExpressions and AttributeExpressions?

[Tyler Baker <tyler@xxxxxxxxxxx>]

"When comparing the name of an element to a QName, the QName is expanded
into a local name and a possibly null URI. This expansion is done in the
same way as for element type names in start and end-tags except that the
default namespace declared with xmlns is not used: if the QName does not
have a prefix, then the URI is null (this is the same way attribute
names are expanded). The expanded element type names are compared (see
Section 2.4.2: Element Nodes)."

This is not clear to me how the QNames for ElementExpressions and
AttributeExpressions are expanded.  In other words, what is the context
to use for resolving the namespace of an ElementExpression or
AttributeExpression QName.

Is the context the stylesheet document?  In this case for a template
match expression would the namespace be the current namespace of the
template element for the given prefix.

Or is the context the current node in the source tree.  In this case for
a template match expression would the namespace be the current namespace
of the current node for the given prefix.

In other words for:

<xsl:template xmlns:foo="http://www.foo.com"; match="foo:bar">
</xsl:template>

When matching an element node that belongs to the namespace
"http://www.baz.org";, does the previous template match expression get
resolved to (using Jim Clark's syntax for explaining XML Names
http://www.jclark.com/xml/xmlns.htm which is about a million time more
useful IMHO opinion in understanding "Namespaces in XML" than the W3C
recommendation as it now stands so I would recommend a reading of it to
any XSL user out there):

<xsl:template xmlns:foo="http://www.foo.com";
match="{http://www.foo.com}bar";>
</xsl:template>

or else:

<xsl:template xmlns:foo="http://www.foo.com";
match="{http://www.baz.org}bar";>
</xsl:template>

Maybe I am just a bonehead here or I have not gotten enough sleep
lately, but after rereading the relevant sections of the December 16
draft, resolving QNames in expressions is not at all clear to me...

Anyways, if anyone has any insight on this, I would greatly appreciate
it.

Thanx in advance,

Tyler

P.S. - Sorry this question is a little late, but I have not really dealt
too much with namespaces to date because:

(1) Virtually no one is using them in XSL as far as I know and will
likely never use "Namespaces in XML" in XSL stylesheets as currently
defined.  To date I have not seen a single stylesheet posted on this
list or else on the web which uses namespaces in XML.
(2) I was hoping that "Namespaces in XML" would either change to
something more manageable or wither away outright or at least that the
XSL architects would choose not incorporate this poor W3C
recommendation.

Due to the statement that:

"XSL processors must use the XML namespaces mechanism [W3C XML Names]
for both source documents and stylesheets. All XSL defined elements,
that is those specified in this document with a prefix of xsl:, will
only be recognized by the XSL processor if they belong to a namespace
with the URI http://www.w3.org/TR/WD-xsl; XSL defined elements are
recognized only in the stylesheet not in the source document."

and the fact that #2 seems a very remote possibility at this point, like
other people on this list I must wrestle with the open-ended questions
that "Namespaces in XML" brings to the table whether I like it or not.

"Namespaces in XML" I feel has given XML itself a black eye to a good
looking face, and likewise "Namespaces in XML" I feel is giving XSL a
bloody nose to a good looking face.  Hopefully, the next working draft
of XSL will take the objective elements of the pros and cons of
"Namespaces in XML" into more careful consideration.

Perhaps a simple poll among members of this list would give the W3C some
insight into whether "Namespaces in XML" even belongs in XSL at this
point.  I am not sure if the W3C cares, but if they do, some simple poll
data might clear a lot of things up.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list