W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: layout changes in operator mapping and descriptions

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sat, 22 Oct 2005 20:34:31 +0100
Message-ID: <435A9447.2080707@hp.com>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: Eric Prud'hommeaux <eric@w3.org>, public-rdf-dawg@w3.org



Seaborne, Andy wrote:
. . .

> Other 3:
> 
> This is an observation and unrelated to the new format. I found in 11.1.1
> 
> """
> XML Schema defines a set of types derived from decimal: integer; 
> nonPositiveInteger; negativeInteger; long; int; short; byte; 
> nonNegativeInteger; unsignedLong; unsignedInt; unsignedShort; 
> unsignedByte and positiveInteger. These are all treated as decimals for 
> arithmetic operations in FILTERs. SPARQL does not specifically require 
> integrity checks on derived subtypes.
> """
> 
> I agree it does not lead to an observable difference (because we have 
> only one version of divide) but the language is different in F&O where 
> it says "integer + integer => integer", not decimal.
> 
> Second table -
> http://www.w3.org/TR/xpath-functions/#op.numeric
> 
> If a custom function were to provide idiv, op:numeric-integer-divide, 
> then the difference would observable because the types of input affect 
> the value out.
> 
> Hmm - that is at odds with the principle that SPARQL operates on values. 
> 1/2 should not depend on whether it's "1"^^xsd:integer or 
> "1"^^xsd:double (in the presence of D-entailment at least).

I was wrong - the definition of op:numeric-integer-divide doesn't lead to this 
situation.

	Andy

> 
>     Andy
> 
Received on Saturday, 22 October 2005 19:34:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT