<-prev [Thread] next-> <-prev [Date] next->
Month Index | List Home

Re: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)

Subject: Re: The top 10 limitations of XSLT 1.0 (was RE: [xsl] RE: Designs for XSLT functions)
From: "Scott Sanders" <satan@xxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 10:24:11 -0800
> evaluate("item[@code = '$1' and @desc = '$2']", $code, $desc)
>
> I do think evaluate() is a very necessary extension to the spec,
even though
> I know it would probably be abused, because:

I agree.  I hope this is not a case of abuse.  If it is, let me know.
There are two extensions in Saxon that I find ABSOLUTELY necessary.

1) saxon:output to output multiple files (the yin to the document()'s
yang)

2) saxon:eval/saxon:expr for dynamcially generating an XPath
expression back into the same source document.  I use it for filling
in HTML Form <input/>s with a value from elsewhere in the document,
and I haven't found any other way to do that.  Example:

<payload>
  <document>
    <form url="http://some.post.url.here";>
      <field name="username" value="User.Name"/>
    </form>
  </document>
  <User>
    <Name>Scott</Name>
    <Address>...</Address>
  </User>
</payload>

With a little translate() User.Name becomes User/Name, and with
concat() we get /payload/User/Name into a variable, and then eval()
gives us the node-set, so the output can be displayed as:

Turns into:

<html>
 ...
  <form...>
    <input type="text" name="username" value="Scott">
  </form>
</html>

Note that I could have the data for the form in a separate document,
but I still have to build the XPath expression at run-time.  Any
suggestions around this are very welcome.

Scott Sanders


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
Current Thread
<- PreviousIndexNext ->
Re: The top 10 limitations of XSLT , Jeni Tennison Thread Re: The top 10 limitations of XSLT , Jeni Tennison
RE: [xsl] Q on xsl:choose, Don Bruey Date RE: [xsl] forcing Line breaks, Michael Kay
Month