[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
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
|