xsl-list
[Top] [All Lists]

Re: [xsl] key() now has 3 arguments ... right

2012-04-24 21:06:38
The reason I didn't comment on David's answer was because I was confused by it.
Now I know why I was confused.

The code from which the snippet I posted was derived  is a tabular
driven utility to rename elements and attributes. No doubt it could be
done another way. The point is it uses a 3 argument key in template
matching patterns and

a) it shows why I wanted to use the 3 argument version
b) it works.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
    xmlns:ren="renames"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
    exclude-result-prefixes="ren"
    version="2.0">

<xsl:output indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:key name="mapNames" match="ren:*/@to" use="../@from"/>

<xsl:variable name="renames">
   <ren:element from="person" to="individual"/>
   <ren:attribute from="firstname" to="christianname"/>
   <ren:attribute from="lastname" to="surname"/>
</xsl:variable>

<xsl:template match="*[key('mapNames',name(),$renames)]">
    <xsl:element name="{key('mapNames',name(),$renames)}">
        <xsl:next-match/>
    </xsl:element>
</xsl:template>

<xsl:template match="*[not(key('mapNames',name(),$renames))] | @*">
    <xsl:element name="{name()}">
        <xsl:next-match/>
    </xsl:element>
</xsl:template>

<xsl:template match="*">
     <xsl:apply-templates select="@*"/>
     <xsl:next-match/>
</xsl:template>

<xsl:template match="@*[key('mapNames',name(),$renames)]">
    <xsl:attribute name="{key('mapNames',name(),$renames)}">
        <xsl:next-match/>
    </xsl:attribute>
</xsl:template>

</xsl:stylesheet>

Try it with

<people>
    <person firstname="Sal" lastname="Mangano" age="38" height="5.75"/>
    <person firstname="Mike" lastname="Palmieri" age="28" height="5.10"/>
    <person firstname="Vito" lastname="Palmieri" age="38" height="6.0"/>
    <person firstname="Vinny" lastname="Mari" age="37" height="5.8"/>
</people









When people ask for reasons why the spec is as it is, there are two ways of
answering:


(b) the post-hoc justification: "can you defend the fact that the spec is
the way it is?". Here I think my answer would be that the syntax for
patterns is a very restricted subset of the syntax of XPath expressions, and
the WG has been traditionally conservative about extending it, probably in
the belief that a smaller language is much more susceptible to the kind of
analysis needed to build an efficient decision tree. There has also been
historically little demand for a more powerful pattern language, with most
users keeping patterns very simple most of the time.

key() in patterns is used very little, and serves very little purpose, since
unlike key() in XPath expressions an index does not help evaluation and
there is really no strong reason to use key() in preference to using a
predicate. Adding the third argument to key() would be oddly asymmetric:
since there is no way in XSLT 2.0 of rooting a pattern such as $x/a/b/c at a
specific document node, it would be odd to allow a key() pattern to be
rooted in that way.

Michael Kay
Saxonica

--~------------------------------------------------------------------
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>
--~--


--~------------------------------------------------------------------
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>
--~--