On 27 Nov 2013, at 06:43, jean-marc Mercier <[email protected]> wrote:
> Hi Michael. thx for pointing me out this link. . It points out also that > "Each entry comprises a key which is an arbitrary atomic value", and that > ordering is implicited by fn:distinct-values. Hence functions or nodes can > not be accepted as keys, neither can we supply external ordering functions. > Maps of maps, maps of nodes are not possible with this specification. > > Is it possible to propose / suggest changes to this specification ? > It's certainly possible to suggest changes. However, these matters have been discussed quite extensively so the WGs will tend to defend the consensus they have already reached. The reason for not having functions as keys is that defining an equality operation on functions is notoriously difficult. The reason for not having nodes as keys is a bit more subtle. There are a variety of possible equality operations on nodes, exemplified by "is", "eq", and "deep-equal". It's not clear that any one of these would meet all use cases. Parameterizing a map to allow user-defined equality or ordering functions as a property of the map is certainly possible, but it all adds complexity [1]. Just because something is possible doesn't mean it is desirable. There's a natural tendency in standards groups to add a feature if one person thinks it is a good idea, despite the fact that everyone wants to keep things as simple as possible. I think we've done well to resist feature creep on this one. Michael Kay Saxonica [1] As an example of the complexity, how do you compare two maps if they have "different" ordering functions, and how can you tell whether the ordering functions are "different" anyway?
_______________________________________________ [email protected] http://x-query.com/mailman/listinfo/talk
