Re: Maps in exslt2?
John Snelson <[email protected]> Wed, 17 Mar 2010 10:38:47 +0000
| Newsgroups | gmane.text.xml.xslt.extensions |
|---|---|
| Message-ID | <[email protected]> |
Hi Vladimir, I think it's really important to get some good data structures into XQuery and XSLT 2.0. I've already written a read/black tree implementation in pure XQuery 1.1 (using 1st class function closures) which I was planning to release via EXPath when appropriate. I designed my map interface like this: declare function map:put( $map as function() as item()*?, $key as item(), $value as item()* ) as (function() as item()+)+ declare function map:get( $map as function() as item()*?, $key as item() ) as item()* declare function map:contains( $map as function() as item()*?, $key as item() ) as xs:boolean declare function map:fold( $f as function(item()*, item(), item()*) as item()*, $z as item()*, $map as function() as item()*? ) as item()* It's a declarative, functional API, so putting an entry into a map creates a new map. The keys are singleton items, and the values are sequences. The map:fold() function visits each map entry executing $f and accumulating a result from it. Looking at the API now, I'm thinking it probably needs map:remove() to remove an entry, and maybe map:keys() to return a sequence of all the keys in the map. I'm also thinking about other useful functional data structures to implement using XQuery 1.1. I'll probably implement a finger tree at some point to use as an array/queue etc. John Vladimir Nesterovsky wrote: >>> The suggestion has been declined (probably my arguments were >>> not convincing). >> You can probably assume that different people voted against it for > different >> reasons. Some may have felt the arguments unconvincing; some may have > felt >> that it was outside the scope of the 1.1/2.1 release (which some people >> think is almost finished); ... > > I can understand arguments of the WG. That is why I'm talking now of exslt, > > and is aiming to binary trees. As items in binary tree algorithms do not > play a role (they are just attached to the tree), implementation is > modular: > > Interface for a tree itself includes functions to: > create a tree (create, insert, remove); > navigate subtree tree (like left, right, size of subtree); > > Map is a tree, which assumes that items are key, value pairs. Thus > interface for the map extends tree with search, and create (create, insert, > > delete) according to a key. > > Tree items should probably be expressed in terms of function items. > The sample implements items as xml elements, which makes it inefficient (in > > xslt 2.1 implementation is efficient if one counts operation complexity). > > But my point was to open a discussion and to show that things are not so > complicated and are very modular. > > P.S. Sorry, if you got this message twice. > -- > Vladimir Nesterovsky > http://www.nesterovsky-bros.com/ > > _______________________________________________ > exslt mailing list > [email protected] > http://www.exslt.org/list -- John Snelson, Oracle Corporation http://twitter.com/jpcs Berkeley DB XML: http://oracle.com/database/berkeley-db/xml XQilla: http://xqilla.sourceforge.net