Re: collations, etc (a list-builtins issue)

Dave Reynolds wrote:
> Sandro Hawke wrote:
>>> I assumed you were talking only about list operators, so I mean 
>>> indeed 1b.

Re-thinking this, we have a problem with collations. If we do not define
which collations are allowed or how to define them (using RIF?) then we 
should exclude either the versions with collations or leave the behavior 
of the versions with collation parameter explicitly undefined.

I made a respective proposal at
http://www.w3.org/2005/rules/wiki/DTB#func:compare_.28adapted_from_fn:compare.29
(func:compare)

and analogously in other functions using collations. The proposal is 
that in RIF we only prescribe the default collation and leave other 
collations unspecified.

Axel

>>>> When you say users "have to define the funtions themselves", you mean
>>>> using rules to re-implement member, index-of, etc?
>>> Yes.
>>
>> Other opinions?  index-of, member, union, etc should just do RIF
>> equality comparison, where the same date expressed in two different time
>> zones wont match, and the same number in two disjoint formats
>> (decimal/float/double) wont match?
> 
> I agree. This seems the simplest to specify and implement starting from 
> where we are now. It is good enough.
> 
> [In retrospect we probably should have had a defined notion of equality, 
> in the XSD sense, for all datatypes as separate from the value space 
> identity notion that RIF "=" supports. Then the operators like member 
> could have used datatype equality rather than RIF equality. Since we 
> don't have that then using anything other than identity for the list 
> operators is going to look ad hoc. ]
> 
> Dave
> 
> 
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Monday, 11 May 2009 23:11:08 UTC