Re: [xslt] key() in match pattern of xsl:key



On Thu, 8 Dec 2005, Daniel Veillard wrote:

> On Wed, Dec 07, 2005 at 11:54:09PM -0500, Joel E. Denny wrote:
> > On Wed, 7 Dec 2005, Daniel Veillard wrote:
> > 
> > >but it's not anything there is
> > >normative prose about nor regression tests to check behaviour.
> > 
> > That's too bad because it seems to work so well if the required 
> > declaration order is known.
> > 
> > Although I'd rather stick with pure XSLT 1.0, I'm thinking about solving 
> > my problem by calling EXSLT user-defined functions in the match pattern of 
> > an xsl:key.  However, after reading this discussion
> > 
> >   http://bugzilla.gnome.org/show_bug.cgi?id=122483
> > 
> > I'm feeling slightly uneasy.  Assuming there are no variable references 
> > anywhere in the dependency chain of the match pattern, this remains 
> > accepted/supported usage, right?
> 
>   I said I didn't intend to change things. This is an Open Source project
> not some black box coming without sources !

I'm sorry I sounded offensive. It seems my wording was horribly ambiguous, 
and you saw the opposite of the meaning I hoped to convey....

By "too bad", I meant it's too bad the W3C didn't specify this so that I 
could use this feature and still write portable XSLT 1.0.  As much as I 
like your implementation, I still want portability.

I figure EXSLT may offer a lesser degree of portability, but it would be 
better than using an implementation-specific feature.  I'm *not* "feeling 
slightly uneasy" about libxslt.  I'm feeling uneasy about whether this 
EXSLT usage is portable.  I was hoping you could shed some light since 
you're such a great advocate for the specs.

> If you care about behaviour
> provide regression tests, check the code, etc ... It's not like I ever
> refused a good argumentation for some code or some regression tests. I
> just refuse to change to make non-conforming behaviour !

I wouldn't want to persuade you to do otherwise.

Thanks for your responses, and sorry again for my confusing email.

Joel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]