Re: A beef with XSLT Sometimes too complicated
> So -- if I follow you -- nesting a for expression is a workaround for > this gap only some of the time? nesting the for never helps, you can use one for if the sequnce being bound to the variable has exactly one item let $x :=1 return ... can be written in xpath as for $x in 1 return .. but there is _no_ way in XPath to bind a value to a variable x such that count($x) has any value other than 1. so let $x := () return ... and let $x := (1,2) return ... have no analogue in XPath. When XPath is used in XSLT it's only a minor inconvenience, you just drop back into xslt and use <xsl:variable name="x" select="()"/> <xsl:variable name="x" select="(1,2)"/> It might be more of a "problem" in oher XPath API, although less of a problem than those API for XPath1, which don't let you bind variables at all, as XPath1 has no binding expressions. > In line with the question whether to prefer XPath or XSLT logic, can > we see an example where we'd actually prefer to do it in XPath if we > could? (I'd welcome entries from anyone.) So if thinking about this "the xpath way" it's probably not much of a problem, but increasingly when looking for xpath solutions you're going to be lead by somone or some search engine to xquery solutions. The fact that often you can get an xpath solution from an xquery solution by replacing any let by for means that people will try that, but it's only safe to do if you know the cardinality of the expression being bound is always 1 (which you are unlikely to know if it's just some code found on the web) I feel a faq coming on in this area... David
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format