RE: How to do an 'existence' test in XSL?

Wendell
I understand the various grouping techniques and the theory behind them.

In this case the OP was grasping for a solution to a *simple* requirement,
in his words.  It's poor form if XSL can only offer a complex solution when
there is a simple need.

When all the possible values are known ahead of time (as is most likely the
case here), then a complex grouping algorithm would certainly not be
acceptable if something simpler would also do the job.

I don't know which solution would provide the best performance in this
instance, but unless this is a particularly performance critical section of
the application, then simplicity should win over performance considerations
every time.

Regards
George

George James Software
www.georgejames.com
An InterSystems Technology Partner



> -----Original Message-----
> From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
> Sent: 22 December 2004 19:25
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  How to do an 'existence' test in XSL?
>
>
> George,
>
> It may not be strictly a full-blown grouping problem, but the
> problem of
> uniquely identifying a single node to stand for a set of
> nodes is part of
> the general problem of grouping. So solutions (and there are
> several) can
> be found in the common solutions for grouping.
>
> Think of it like this: group the nodes, and for each group
> report a single
> value. You don't need to know ahead of time what those values
> might be.
>
> At 01:38 PM 12/22/2004, you wrote:
> >Mukul
> >To me, your solution is not as simple as it could be.
>
> Mukul's solution is to test on the preceding-sibling axis to
> see whether
> any nodes preceding have the same value, and can therefore be
> presumed to
> be accounted for.
>
> It may not be the most elegant approach imaginable (as Mike
> said you have
> to go to XSLT 2.0 for that), and it is not very performant over large
> datasets, but it works ... and it's not that complicated either.
>
> Other approaches to identifying what I call a "flag-bearer"
> node include:
>
> B. setting up a key and then seeing whether each node is the
> first (or
> last, if you like) returned by the key with its key value
>
> C. doing brute force retrieval of the nodes like this one,
> and seeing if
> this one is the first
>
> B is often the preferred approach, as being both not overly
> complex, and
> performant even over fairly large data sets. Whether it's
> "simple" depends
> on whether you consider keys simple. (I think they're pretty
> simple, but
> then I've got an XSLT 1.0 processor installed in my brain.)
>
> All these will work over node sets whose relevant values ("alertbox",
> "tooltip", "help") are not known ahead of time.
>
> As Mike indicated, the techniques are documented in Jeni's pages on
> grouping at www.jenitennison.com/grouping. And as he also
> indicated, the
> particular feature of the language wanted -- a gap filled in
> XSLT 1.0 by
> the grouping techniques just described above -- is actually
> provided in
> XSLT 2.0's "for-each-group" construct.
>
> Cheers,
> Wendell
>
>
>
> ======================================================================
> Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
> Mulberry Technologies, Inc.                http://www.mulberrytech.com
> 17 West Jefferson Street                    Direct Phone: 301/315-9635
> Suite 207                                          Phone: 301/315-9631
> Rockville, MD  20850                                 Fax: 301/315-8285
> ----------------------------------------------------------------------
>    Mulberry Technologies: A Consultancy Specializing in SGML
> and XML
> ======================================================================
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22/12/2004
>
>

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: 22/12/2004