RE: The evaluate function

Actually, I'd be surprised if the list archive contains a single real-world
example which can't be solved without evaluate() and isn't also an example
of bad design. The ones I remember included reading XPath expressions from
XML files, which could have been avoided by "XML-ifying" the expression.

Please explain. If I understand what's implied, that wouldn't handle full
XPath expressions (complete with embedded evaluable expressions) - only
path-to-root expressions. To evaluate full XPath,  you'd end up having to
write your own XPath expression evaluator in XSL, and I don't suppose that
would perform quite as well :-)

BTW, if I'm not mistaken, it's the lack of a standard "evaluate" function
that forces systems like Schematron into being two-pass (generate and
execute). Efficiency arguments aside, with an evaluate function, the rules
could be read and evaluated in one pass. In an environment where the rules
are generated more dynamically, a two-pass approach wouldn't fly, anyway.

Mark


----------------------------------------------------------------------------
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@xxxxxxxxxxxxxxxx
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com  
 

 -----Original Message-----



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