This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Default attribute value templates


Thanks to Mike Kay and Dimitre Novatchev for their answers addressing
the example given.  The bottom line seems to be that using AVTs for
xsl elements which have defaults is a tricky business.

My example was over simplified: I want all the attributes of xsl:sort
(except "select" which is another problem entirely) not just 'order'.

Original example:
>> I have a template which matches a specific element, then does an
>> apply-templates with a sort.  The application is supposed to be fairly
>> generic, so it seems a nice idea to allow those attributes of sort
>> which are attribute value templates to be parameterized thus:
>> 
>> <xsl:template match="x">
>>      <xsl:apply-templates>
>>            <xsl:sort order="{@order}" ... />
Notice the '...'
>>      </xsl:apply-templates>
>> </xsl:template>
>> 
>> The problem is, given <x>...</x> the transformation fails "order must
>> be ascending or descending".
>> 

Mike Kay: 
>You can write
>order="{concat(substring('ascending', 1, 9*not(@order)), @order)}"
>
Sneaky.  I guess wiring in the default is not a problem for something
as stable as xsl:sort.  There is a problem though: for the 'lang' and
'case-order' attributes we do not know what the default is, because it
depends on the environment.

Dimitre Novatchev:
><xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
><xsl:template match="x">
>  <xsl:choose>
>    <xsl:when test="@order and (@order = 'ascending'
>                                or @order = 'descending')">
Aside: I think you intended to validate that the order attribute if
supplied is a valid value: good idea in principle, but as it stands
this silently throws away invalid values.
>       <xsl:apply-templates>
>           <xsl:sort order="{@order}"/>
>       </xsl:apply-templates>
>    </xsl:when>
>    <xsl:otherwise>
>       <xsl:apply-templates>
>           <xsl:sort/>
>       </xsl:apply-templates>
>    </xsl:otherwise>
>  </xsl:choose>
></xsl:template>
>
></xsl:stylesheet>

Yes, thats the sort of thing I had in mind.  The problem is xsl:sort
has four attributes which take AVTs, which makes 16 xsl:whens and 16
copies of the xsl:apply-templates which could have all sorts of other
stuff like modes, selects, with-params etc.  Bad news for maintenance
and testing.  If we use Mike's method where it applies this comes down
to 4, but its still uglier than I like.

I think I will do two passes: the first to generate a stylesheet with
the right xsl:sort in it, then a second to apply it.  This lets me
parameterise 'select' as well, and with a change to the way 'x' is
defined allow more than one sort key.

Thanks again,
Trevor Nash

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]