RE: [xsl] Namespace wildcards

I agree that doing anything to make namespaces more confusing is not ideal,
but in this case, I think the solution we proposed in 2.0 is valid. Anyone
new to XSLT will automatically try *:set first. Getting to
*[local-name(.)="whatever"] is a bit more convoluted and most beginners may
give up before they reach that solution on their own.

Zarella


> -----Original Message-----
> From: www-xpath-comments-request@w3.org
> [mailto:www-xpath-comments-request@w3.org]On Behalf Of Michael Kay
> Sent: Saturday, February 02, 2002 8:20 AM
> To: xsl-list@lists.mulberrytech.com
> Cc: www-xpath-comments@w3.org
> Subject: RE: [xsl] Namespace wildcards
>
>
> > -----Original Message-----
> > From: owner-xsl-list@lists.mulberrytech.com
> > [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of Elliotte
> > Rusty Harold
> > Sent: 01 February 2002 20:00
> > To: xsl-list@lists.mulberrytech.com
> > Cc: www-xpath-comments@w3.org
> > Subject: [xsl] Namespace wildcards
> >
> >
> > In light of all the issues with namespaces that already exist, I feel
> > compelled to ask whether the namespace wildcards introduced in XPath
> > 2.0 <http://www.w3.org/TR/xpath20/#node-tests> are a good idea. This
> > enables expressions like this:
> >
> >
> > <xsl:template match="*:set">
> >    This matches MathML set elements, SVG set elements, set elements
> >    from other  namespaces, and set elements from no namespace at all.
> > </xsl:template>
> >
> > In other words the local name matters, but the URI doesn't. Do we
> > really want to allow this? Do we actually need this? I'm really
> > afraid this is going to further confuse developers about namespaces
> > and encourage bad practices.
>
> I agree it's open to misuse, but there are cases where it is genuinely
> useful. I've heard of a number of cases (though I can't cite them) where
> people have used different namespaces to represent versions or variants of
> an XML vocabulary, but where the variants are sufficiently close
> to make it
> possible to write stylesheets that can handle all of them.
>
> Mike Kay
>
>

Received on Monday, 4 February 2002 18:33:32 UTC