Re: new ValueTesting tests

On Tue, Aug 02, 2005 at 11:34:05AM +0100, Seaborne, Andy wrote:
> 
> 
> 
> Eric Prud'hommeaux wrote:
> >Look ma, I made (
> >     [  mf:name    "extendedType-literal-eq" ;
> >        rdfs:comment "Test FILTER match on extended type." ]
> >
> >     [  mf:name    "extendedType-literal-ne" ;
> >        rdfs:comment "Test FILTER negative match on extended type." ]
> >
> >     [  mf:name    "extendedType-graph" ;
> >        rdfs:comment "Test graph match on extended type." ] ) and
> >tested them all. Can I have my gameboy back now?
> 
> Before you get your gameboy back ...
> 
> I am unclear as to what happnes with this:
> 
>   'XXI'^^:romanNumeral  = 21
> 
> Is it an evaluation failure (types not compatible) or false (not known to 
> be true).
> 
> It says (11.2.3.1):
> 
> """
> 11.2.3.1 sop:RDFterm-equal
> 
> Returns TRUE if the two arguments are the same RDF term or if they are 
> literals known to have the same value. The latter is tested with an XQuery 
> function appropriate to the arguments.
> """
> 
> Which XQuery function is to be applied in the case of an unknown datatype?
> 
> 
> Another way of asking the question might be what happens about any type 
> promotion for RDF terms because r:Term is a super type of r:Literal but is 
> r:Literal a supertype of something xsd:integer?  I think rq23 does not say 
> it is.
> 
> And for:
> 
>   'XXI'^^:romanNumeral  != 21
> 
> If that is false (not known to be the same value) and not an evaluation 
> failure, how does it work for incompatible types?  is it the case that 
> there is no possible evaluation failure based on incompatible types?

I think it's a type error. That is, the != operator takes any of a
defined set of parameters and :romanNumeral is not in the list. I
pestered Liam about this (text below), but I haven't gotten anything
back from him. He and others are all probably distracted by
extreme. I'm re-posting my question to Don Chamberlin.

I'M taking however it operates in XQuery as the way it operates in
SPARQL. If my understanding is correct, I'll fix the list
in 11.2.1 Invocation [INV]:

 o Arguments expressions are evaluated...
s/Arguments/Arguments'/

 o For functions and operators where the result type is specified ...
s/result type/parameter type/

add this text to the last paragraph:

 If any of these steps fails, the invocation generates an error.
+Invoking a function or operator with arguments that are not known to be
+the correct type generates a type error.
 The effects of type errors are defined in SPARQL Functions and Operators.

and insert a 2nd paragraph below Table 11.1 Operator Mapping:

+Some operators are defined for more than one set of parameter
+datatypes. An operator invoked with parameter datatypes not listed
+below generates a type error.

Aside re "known to be the correct type":
So far, we've been assuming that the way an impl knows about a
romanNumeral being a restriction of decimal is that the implementor
typed the appropriate code it. However, some types may be fully
defined by an XML schema. e.g. my:positiveIntegerBetweenThreeAndFive
is lexically compatible with, and fully defined by restriction from,
xs:positiveInteger. But we don't know much about the interaction of
XML Schema and RDF so oh well.

[INV] http://www.w3.org/2001/sw/DataAccess/rq23/#invocation
--------8<----------------------------------------------
Given:
  attribute     lexical         type
  @l            XXI             my:romanNumeral
  @r            21              xs:decimal

How does @l=@r evaluate if XXI is known to be a restriction on
xs:decimal? How about if that is not known? Is that false, or a type
error? Is the difference detectable by evaluating @l!=@r ?

My interpretation is that the operator table says several
possibilities for what A=B means. If your pattern isn't found,
you have a type error. Therefor, when my:romanNumeral is not
known to be a restriciton, and therefor, covered by
numeric=numeric, the result is a type error, which is, at EBV
time, FALSE. '!' doesn't mask a type error, so @l!=@r is a type
error and, ultimately, FALSE.

                        @l=@r           @l!=@r
 is a restriction       TRUE            FALSE
not a restriction       FALSE           FALSE

--
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

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