Re: Preliminary material for section "value testing"

On Tue, Oct 12, 2004 at 01:58:47 +0100, Andy Seaborne wrote:
> 
> I have put some very preliminary text about value testing in:
> 
>    http://jena.hpl.hp.com/~afs/value-testing.html

Overall seems good, but I'm concerned about the number of functions and 
the complexity of some of them.

Agree about the oddity of having datatype pricessing in one place and not
the other being potentially confusing, but they are different, and the
implementaion complexity of handling datatype objects specially is not
small. Also if we requre that triple expression do datatype manipulation
then we may require some other means to explicitly turn it off. e.g.
1.00000000001f != 1.

op:numeric-equal doesnt descuss floating point formats, the result of
op:numberic-equal(a, b) where a and b are fp should probably be undefined,
with formats like IEEE-768 is is not really posibly to answer, and without
requiring SPARQL implementations to provide thier own software fp bit
opertations we cant sensibly require a given behaviour. Each VM/processor
will give different results (if its even supported).

I forget the situation with <= and >=, but I think they may be OK.

fn:round-half-to-even() is pretty obscure, and may not be provided by many
environments.

ditto with some of the Functions on Strings: fn:substring-before,
fn:substring-after, fn:string-join (seems like an array operator to me),
fn:normalize-space, fn:normalize-unicode (ouch!),  fn:escape-uri (hard to
define as many systems with want to use the underlying URL escaping
features of thier enviroment, not make one to SPARQL spec).

fn:matches states perl5 regex, but that seems a bit onerous for ssytems
that are eg. based on JavaScript, building a complete perl5 regex engine
seems like too much work. POSIX would be more reasonable IMHO.

isBound seems like an unneccesary depature from SQLs IS NULL, but I'm not
that bothered, just mentioning it.

- Steve

Received on Wednesday, 13 October 2004 16:41:59 UTC