Re: EBV of invalid numeric literals

Heya Jeremy, I thought I'd see if you knew the answer to this one off
the top of your head. I think the question is basically what is the
denotation (in mt tersm) of "bla"^^xsd:integer .

Thoughts so far:

- There is no <"bla", x> in xsd:integer.
- It would be impractical to demand that SPARQL work only on consistent
  graphs (since it's a moving target).
- Even consistent wrt a subset of xsd-entailments (
    * xsd:integer
    * xsd:decimal
    * xsd:float
    * xsd:double
    * xsd:string
    * xsd:boolean
    * xsd:dateTime
  ) would be impractical as the insertion of "bla"^^xsd:integer wold
  make the whole graph disappear (or fall outside SPARQL).
- Maybe the triple {_:bob foaf:age "bla"^^xsd:integer} simply doesn't
  exist, but then the graph-pattern-matching part of SPARQL has to do
  expensive validity checking best left for FILTERs.
- EBVs and XPath invocation text could say that illegal lexical values
  result in err:FOCA0002: Invalid lexical value.
  -- http://www.w3.org/TR/xpath-functions/#ERRFOCA0002


Arjohn's comment was about the boolean value of "bla"^^xsd:integer (say
FILTER ("bla"^^xsd:integer && TRUE)) but it also pertains to the rest
of the XPath-based operators ("bla"^^xsd:integer + 7). Their invocation
is defined in
  http://www.w3.org/2001/sw/DataAccess/rq23/rq25#operandDataTypes


Is the answer already in there? Do I just need some explanatory text?

* Arjohn Kampman <arjohn.kampman@aduna-software.com> [2007-07-18 14:28+0200]
>
> Dear DAWG,
>
> It's not completely clear to me what the Effective Boolean Value of
> invalid numeric literals should be. I have been unable to find a
> decisive answer in the current SPARQL specification.
>
> The current definition of EBV states:
>
>   "If the argument is a numeric type or a typed literal with a datatype
>    derived from a numeric type, the EBV is false if the operand value is
>    NaN or is numerically equal to zero; otherwise the EBV is true."
>
> With this definition, it's clear that the EBV of "0"^^xsd:integer should
> be <false> and the EBV of "12345"^^xsd:int should be <true>. However, it
> doesn't exactly cover the case of invalid numeric literals like
> "bla"^^xsd:integer. I assume that this would result in a type error, but
> with the definition quoted above it could just as well evaluate to
> <true>.
>
> The EBV definition for boolean literals is a little clearer, but it also
> leaves room for interpretation.
>
> I would appreciate it if someone could clarify what the expected
> behaviour should be.
>
> Thanks,
>
> Arjohn
>
> -- 
> Arjohn Kampman, Senior Software Engineer
> Aduna - Guided Exploration
> www.aduna-software.com

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.