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

[Daniel Veillard <veillard redhat com>]

On Thu, Dec 08, 2005 at 04:08:03AM -0500, Joel E. Denny wrote:
> 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.

  oh, okay, sorry for the misunderstanding :-)

Daniel

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