RE: [xsl] XML Schema/XSL conflict (can't differentiate unqualified locals)?

["Evan Lenz" <elenz at xyzfind dot com>]

Brian Atkins wrote:
> Thus, in the following document, there is, to my knowledge (such
> as it is), no
> way to differentiate the two 'spam' elements from different namespaces
> (at least without including enough of the ancestors to get back to a
> qualified global) in an XSL stylesheet.  Am I missing something?

XSLT supports namespaces as defined in the XML Namespaces recommendation.
I'm not sure what the XML Schema wording is on unqualified local element
types, but the word "unqualified", at least to me, suggests that XML Schema
treats both "spam" elements as not in a namespace, and thus having the same
universal name. At least this is how they are defined in the XML Namespaces
recommendation.

> Perhaps the answer is that the author of schema doc.xsd must realize that
> anyone who wanted to differentiate spam elements (a possible conflict
> due to that authors definition of the "any" namespaces) would
> need to qualify
> locals and set elementFormDefault, or form, accordingly.

The defaulting of the default to unqualified is unfortunate, IMHO. It
encourages a practice that many consider to be bad. There has been a lengthy
discussion of this on xml-dev. One possible starting point for your reading:
http://lists.xml.org/archives/xml-dev/200108/msg00017.html

> I don't
> think this
> is reasonable, however, since they may not know the other schema that well
> (imagine the schema author wanted to allow HTML or WML to be the content,
> but not being an expert at either).

XHTML has its own namespace. Accordingly, it is widely considered best
practice to use a namespace for embedded vocabularies. In any case, doesn't
Schema let you declare local elements that are unqualified if the default
isn't unqualified? Maybe not...

Ultimately, yes, there may be a mismatch, insofar as XML Schemas attempts to
extend the namespaces mechanism as provided by the XML Namespaces
recommendation, and XSLT does not support that extended mechanism.

As long as you employ this practice, you will always need to do the
following:

<xsl:template match="t1:test/spam">

and

<xsl:template match="t2:test/spam">

Hope this helps,

Evan Lenz
XYZFind Corp.


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