mixed datatypes and aggregates (was: Re: Views on the outcomes of F2F)

Andy Seaborne wrote:

>  > **  ISSUE-16: Mixed datatypes with built-in aggregates
>  >
>  > Consensus that MIN/MAX should use same semantics as ORDER BY,
>  > with parts (e.g. ordering xsd:string and xsd:dateTime) being
>  > undefined/implementation defined.
> 
> I think this will get confusing with mixed data "1", "9", 1, 2, 3 but 
> may be acceptable.  

I don't think this is confusing - it's the same behavior as with the 
built-in functions (you can't add "1" and 1 or order by "1" and 2).

> (Multivaluespace handling is still my preferred 
> design.)

There was very strong consensus against this design from the attendees 
at the face to face.

> If eval failures, are "not in group", casting is OK but the document 
> must talk about this.

Yes, of course. The idea was that an aggregate function could evaluate 
to a type error - what to do about the type error would be handled by 
the general treatment of type errors in project expressions (see next 
issue) or in the FILTER/HAVING clause (effective boolean value).

>  > Consensus that SUM/AVG should use same semantics as +
> 
> Clarification: errors not in a group means that what would be
> 
> 1 + error + 2 => 3
> 
> which is not the same as +

No, the consensus was 1 + error + 2 => error.

(I'll leave the rest to the continuing "semantics of SUM" thread.)

Lee

Received on Friday, 13 November 2009 04:47:45 UTC