Re: xsl:key support (was RE: Simple XPath question)

Subject: Re: xsl:key support (was RE: Simple XPath question)
From: "Steve Muench" <smuench@xxxxxxxxxxxxx>
Date: Mon, 22 Nov 1999 15:40:44 -0600
Not sure about others but I know that
the Oracle XSLT Engine (part of our integrated
Oracle XML Parser for Java/XPath/XSLT implementation)
supports the XSLT Recommendation, including <xsl:key>

Release 2.0.2.4 is the latest available.

See:  http://technet.oracle.com/tech/xml

for more info.

Thanks.

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Vun Kannon, David <dvunkannon@xxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Monday, November 22, 1999 3:48 PM
Subject: xsl:key support (was RE: Simple XPath question)


| Is there any XSLT engine today that supports <key/> and key()?
|
|
| -----Original Message-----
| From: Phil Lanch [mailto:phil@xxxxxxxxxxxxxxx]
| Sent: Monday, November 22, 1999 12:09 PM
| To: xsl-list@xxxxxxxxxxxxxxxx
| Subject: Re: Simple XPath question
|
|
| "Vun Kannon, David" wrote:
| >
| >         Shouldn't the concatenated string Phil constructs below be the
use
| > attribute of a key:
| > <key name="FL" match="PERSON" use="concat(string-length(@firstname),
| > ' ',concat(@firstname,@lastname))"/>
| >
| >         Then the function
| > key('FL',concat(string-length(@firstname),'
| ',concat(@firstname,@lastname)))
| > could be used in an expression to find node sets of size > 1. That XT
| hasn't
| > implemented the key stuff yet limits my ability to test this conjecture.
|
| Ah. I was nowhere near coming up with that.
|
| It looks good to me.
|
| How about ...
|
| <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
| version="1.0">
|     <xsl:key name="FL" match="PERSON"
|     use="concat(string-length(@firstname),'
| ',concat(@firstname,@lastname))"/>
|
|     <xsl:template match="/">
| <xsl:apply-templates
| select="//PERSON[ count( key('FL',concat(string-length(@firstname),'
| ',
| concat(@firstname,@lastname))) ) &gt; 1 ]"/>
|     </xsl:template>
|
|     <xsl:template match="PERSON">
| ... process a non-unique person ...
|     </xsl:template>
| </xsl:stylesheet>
|
| ... I haven't been able to test this, either.
|
| The downside is that keys are (of course) only part of XSLT, not XPath,
| and Paul originally asked whether a pure XPath solution was possible.
|
| Well, at least we haven't used variables.
|
| A 'Simple XPath question', indeed ...
|
| >         BTW, is this concat idiom the right way to construct a key whose
| > value spans more than one node?
|
| It's cetainly not elegant.
| Any better ideas would be appreciated.
|
| > Cheers,
| > David vun Kannon
| >
| > -----Original Message-----
| > From: Phil Lanch [mailto:phil@xxxxxxxxxxxxxxx]
| >
| > David Carlisle wrote:
| > >
| > > It doesn't work as
| > > >  following-sibling::PERSON/@lastname = ./@lastname and
| > > >  following-sibling::PERSON/@firstname = ./@firstname
| > >
| > > does not force that it is the same following-sibling. ie it selects
| > > a PERSON if some later person has the same firstname, and a third
person
| > > has the same lastname.  You can make the selection in various ways in
| > > xslt but I suspect Paul is right that you can't do it in a single
| > > xpath expression unless you give yourself an extension function that
| > > (say) returns a string uniquely generated from the firstname and
| > > lastname attributes of an element node, then you could do
| > >
| > > dpc:bothnames(following-sibling::PERSON)=dpc:bothnames(PERSON)
| >
| > Using just the built-in functions,
| > it's possible to get a string uniquely generated from the firstname and
| > lastname attributes of _one_ element node, e.g.:
| >
| > concat(string-length(@firstname),' ',concat(@firstname,@lastname))
| >
| > The problem is that we need your
| >
| > dpc:bothnames(following-sibling::PERSON)
| >
| > function to return a list of these uniquely generated strings,
| > and a list of strings
| > (as opposed to a list of nodes that happen to be text nodes)
| > is of course not a valid XPath type.
|
| --
|
| cheers
|
| phil
|
| '"having more of a life is one of the earliest
|   and subtlest signs of mediocrity"' --- Musil
|
|
|  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
|
****************************************************************************
*
| The information in this email is confidential and may be legally
privileged.
| It is intended solely for the addressee. Access to this email by anyone
else
| is unauthorized.
|
| If you are not the intended recipient, any disclosure, copying,
distribution
| or any action taken or omitted to be taken in reliance on it, is
prohibited
| and may be unlawful. When addressed to our clients any opinions or advice
| contained in this email are subject to the terms and conditions expressed
in
| the governing KPMG client engagement letter.
|
****************************************************************************
*
|
|
|  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
|


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


Current Thread