[
Lists Home |
Date Index |
Thread Index
]
Michael Kay <michael.h.kay@ntlworld.com> writes:
>
> The facility you appear to be looking for is dyn:evaluate()
> as defined in www.exslt.org. It's not available in standard
> XSLT 1.0 or 2.0, but is available (in some form or another)
> in a number of XSLT processors including Saxon and Xalan.
>
I was tempted to suggest evaluate but the wording of the original
suggestted that he did not know how many arguments he had to traverse,
in which case you can't really get generalized argument handling in XSTL
that I'm aware of?
I seemed to miss his response to me, more comments below...
> Michael Kay
>
> > -----Original Message-----
> > From: Mark Heieis [mailto:mark.heieis@shaw.ca]
> > Sent: 30 July 2004 18:31
> > To: 'Hunsberger, Peter'; xml-dev@lists.xml.org
> > Subject: RE: [xml-dev] Dynamically creating a pattern for
> > xsl:apply-templates select
> >
> > The environment is standalone that generates XML which is
> > then converted
> > for viewing and final o/p - i.e. no web functionality, just
> html file
> > creation for local viewing.
> >
> > The task is to replace tokens in the source XML with user
> > tokens, which
> > sit in an other external XML file.
> >
If you've got two XML files then I don't see why you're trying to filter
everything by building up the xPath in the manner you show? There are
lots of ways to do this, the xslt list is the place to ask, but
basically, if you want to filter on an attribute name "attr" then
<xsl:variable name="filternodes"
select="document('filterfile.xml')/nodes_of_interest"/>
and
curnode[@attr = $filternodes/@attr]
Would match curnode if it had an "attr" that was also present in the
filternodes file. Same basic principle applies to elements, though you
may want to match on local-name() depending on whether you want to
ignore namespaces.
> > We're using java 1.4 and its XML libs but there is nothing
> stopping us
> > from using SAX or even XPATH 2.0, if it can help.
> >
> > I actually have everything working (by hard coding), except for the
> > ability to handle the unknown/dynamic capability aspect.
> >
> > Thanks.
> >
> > mrh.
> >
> > -----Original Message-----
> > From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> > Sent: Friday, July 30, 2004 07:59
> > To: Mark Heieis; xml-dev@lists.xml.org
> > Subject: RE: [xml-dev] Dynamically creating a pattern for
> > xsl:apply-templates select
> >
> >
> > Mark Heieis <mark.heieis@shaw.ca> writes:
> >
> > >
> > > I have some challenges to solve:
> > >
> > > I need to parse a string that contains n number of args,
> which is in
> > > the form of "arg1, arg2,...argn". The args define either an
> > attribute or
> > > element value. The goal is to prune a large tree using the
> > > given arguments.
> > >
> > > I want to dynamically create a pattern for the following
> using the
> > > above input string, such that
> > >
> > > <xsl:apply-template select=path/node[@name=$arg1 or
> @name=$arg2
> > > or @name=$argn]/>
> > >
> > > is made to look something like
> > >
> > > ...
> > > <xsl: variable name="pattern">@name=$arg1 or @name=$arg2 or
> > > @name=$argn</xsl:pattern> or
> > > <xsl: variable name="pattern">@name='$arg1 | $arg2 |
> > > $argn'</xsl:pattern>
> > > ....
> > >
> > > which would then be used as
> > > ...
> > > <xsl:template match='somecondition''>
> > > <xsl:apply-templates select=path/node[$pattern]/>
> > > </xsl:template>
> > >
> > > The questions are:
> > > Can the select attribute accept pattern defined by a variable? So
> > > far I haven't been able to make it work.
> > > If yes, how should it be constructed based on the given input
> > > string? If no, what would be an approach to filter a tree
> > > based on the given input? Or even if yes, is there a better
> > > way to filter a large tree?
> >
> > You don't say what tools you have access to or are willing
> to use, but
> > I'll outline one approach you can use. The general issue here is
> > traversing the arguments and the suggestion of building an
> > intermediate style sheet doesn't really help you if you
> don't know in
> > advance how many arguments you are going to get. If that's
> the case
> > I'd convert the
> > arguments into a node set. Two ways to do this: an XSLT
> extension (if
> > you're willing to do that), or some pre-processor (in
> procedural code)
> > that builds an XML file (or SAX stream) of some kind out of
> them. Once
> > you've got a node set filtering one node set based on the
> contents of
> > another node set is a pretty straight forward process.
> >
> > If you've got a lot of this kind of thing to do then you
> may want to
> > look at the Apache Cocoon project. It, for example, includes a
> > standard component to turn HTTP requests parameters into a
> SAX stream
> > that can be
> > aggregated with a XML file reader component Sax stream and
> > the combined
> > output can then be fed into a regular XSLT, no Java coding required.
> > However, be forewarned, jumping into Cocoon isn't exactly
> > trivial; it's
> > a big piece of machinery meant for solving complex problems..
> >
> >
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
>
>
>
|
