Subject: Re: Re: How to do an 'existence' test in XSL?
From: Dimtre Novatchev <dnovatchev@xxxxxxxxx>
Date: Fri, 24 Dec 2004 06:14:48 +1100
|
Hi Ben,
> P.S. If Dimtre fancies explaining in a little more detail what on earth is going on in his
> script below that would be a wonderful thing!
Nothing complicated is happening in "the script" -- you wanted to say
in the transformation or in the solution.
Comparing for equality, where one of the arguments is a node-set is
something fundamental in XPath.
I am using XSLT 2.0, but this is only for convenience, because due to
being lazy I don't want to model a sequence in XSLT 1.0 by a node-set.
Apart from this small difference, the XSLT 1.0 solution would be very
much the same.
Cheers,
Dimitre.
On Thu, 23 Dec 2004 11:38:19 +0000, ben@xxxxxxxxxxxxx <ben@xxxxxxxxxxxxx> wrote:
>
> George certainly has a point... computer languages are modelling languages. If they are not able to elegantly model a common phenomenon (which this is) then they aren't doing their job too well, doubtless why XSL 2.0 has this new property.
>
> However, the scenario I outlined was overly simplistic.
>
> +It should not be assumed that the gui tags are are siblings. They may be scattered throughout the document at various nestings+
>
> One of my additional problems is that I am using PHP5 and thus James Clark's expat parser, which doesn't support keys?
>
> In this case I wonder which of the various proposed techniques will work!
>
> Many thanks for all the input, the discussion certainly highlights many potentially useful approaches for an XSL beginner such as myself!
>
> Ben
>
> P.S. If Dimtre fancies explaining in a little more detail what on earth is going on in his script below that would be a wonderful thing!
>
>
> You wrote:
> > In case you know all possible types in advance, a simple (but not
> > too-efficient) way of picking up all "existing" gui types is the
> > following:
> >
> > <xsl:stylesheet version="2.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > >
> >
> > <xsl:output method="text"/>
> >
> > <xsl:param name="pAllStyles" as="xs:string+"
> > select="'alertBox', 'combo', 'help', 'tooltip'"/>
> >
> > <xsl:variable name="vDoc" select="/"/>
> >
> > <xsl:template match="/">
> > <xsl:value-of separator="
" select=
> > "$pAllStyles[. = $vDoc/styles/gui/@type ]" />
> > </xsl:template>
> > </xsl:stylesheet>
> >
> > When this transformation is applied on your source xml (provided with
> > a single element parent):
> >
> > <styles>
> > <gui type="alertBox"/>
> > <gui type="tooltip"/>
> > <gui type="help"/>
> > <gui type="tooltip"/>
> > <gui type="alertBox"/>
> > <gui type="tooltip"/>
> > <gui type="help"/>
> > </styles>
> >
> > the wanted result is produced:
> >
> > alertBox
> > help
> > tooltip
> >
> >
> > Cheers,
> > Dimitre.
> >
> >
> >
> > On Wed, 22 Dec 2004 14:33:06 +0000, ben@xxxxxxxxxxxxx <ben@xxxxxxxxxxxxx> wrote:
> > > I'm having great difficulty understanding how/if XSL provides the tool to satisfy the following simple requirement.
> > >
> > > Lets say I have some simple xml like :
> > >
> > > <gui type="alertBox">...</gui>
> > > <gui type="tooltip">...</gui>
> > > <gui type="help">...</gui>
> > > <gui type="tooltip">...</gui>
> > > <gui type="alertBox">...</gui>
> > > <gui type="tooltip">...</gui>
> > > <gui type="help">...</gui>
> > >
> > > To simplify things... imagine transforming this document in such a way that we have something like :
> > >
> > > <alertBox/>
> > > <tooltip/>
> > > <help/>
> > >
> > > i.e. I would like the XSL to result in one output per gui type.
> > >
> > > So there is the problem... how on earth do I process the xml such that it results in an output per +type+ rather than for each instance (is that explained well enough?)... i.e. it's easy to match on the attributes but each match produces output so I would get :
> > >
> > > <alertBox/><alertBox/>
> > > <tooltip/><tooltip/><tooltip/>
> > > <help/><help/>
> > >
> > > Can anyone offer advice on the way in which I ought to approach this problem?
> > >
> > > Kindest regards,
> > >
> > > Ben
|