Re: [xslt] support of attribute value templates in xsl:sort

[Daniel Veillard <daniel veillard com>]

  Hi Ken,

On Wed, Jul 03, 2002 at 07:08:02PM -0700, Ken Neighbors wrote:
> I found that libxslt does not support "data-type" and "order" as
> attribute value templates in xsl:sort.  As a simple example,
>   <xsl:sort data-type="{'number'}">
> silently sorts the data as text.

  yep, this was missing !

> Furthermore, an invalid value for the data-type is treated as "number"
> instead of the default value of "text".  Of course erroneous input
> should not guarantee a result one way or the other, but it seems to me
> that the intuitive behavior is that it should revert to the default.
> Similarly, an invalid value for "order" is treated as "descending"
> instead of the default value of "ascending".

  yes, this makes sense !

> Using xsltNumberFormat in numbers.c as a guide, I patched
> xsltDoSortFunction in xsltutils.c to support attribute value templates
> for "data-type" and "order".  Adding this support seemed to me like
> the "right thing to do", but of course I am biased because I need this
> feature so discussion is welcome.  The only part I felt reservations
> about was cut-n-pasting code from preproc.c into xsltutils.c because
> now this code appears in two places so it is redundant.  But I'm not
> sure how else to do it, except maybe by overhauling the whole
> treatment of "static" versus "dynamic" attribute value templates,
> which I am definitely not prepared to do.

  In that case a bit of duplication is not a big deal, no problem. And
since the problem is now exposed and logged that's fine !

> I also patched preproc.c and xsltutils.c to use the default value for
> an invalid "data-type" or "order".  I do not feel strongly if you wish
> to remove this behavior, especially if there was a reason that it
> should behave the non-default way. 

  No reason, it's just that that part was overlooked !

> Detail: given valid input, the
> flags for data-type and order are set to zero for default behavior and
> they are set to one for non-default behavior.  But given invalid
> input, these flags were set to -1, which was interpreted elsewhere in
> the code as non-default behavior.  I did not see that this value of -1
> was used anywhere in the code, so I set them to zero when given
> invalid input to get the default behavior.  I hope that made sense.
> Perhaps looking at the patch will help.

  yes, this makes sense, I applied and commited the patch. Thanks again
for looking into this issue and coming up with both a patch and complete
explanations !!!

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/