Re: Transitive closure for XPath

[Sorry about the delayed response]

Michael Kay wrote:
> 
> > So we would still have a closure() function but have a notation for
> > delayed evaluation:
> >
> >       closure(/closure/node[1], delay::key("myKey", @child))
> >
> 
> The concept you are looking for is "higher-order functions", available in
> many functional programming languages. The concept is consistent with the
> XPath conceptual model, but disagreeable to those who want the language to
> stop short of being a general purpose programming language.
> 
I don't want to see XSLT becoming a general purpose programming language
but I would like to see it become an exceedingly good XML transformation
language. 

Closure looks to me very like a solution to the "parts explosion"
problem in SQL - did support  for this ever reach one of the SQL
standards? 

It seems to be a wide and relevent requirement for a language
specialised to manipulating a specific type of data structure. 

Francis.

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