Re: [edits in 1.505] reworking errors SPARQL Query

On Tue, Oct 11, 2005 at 01:51:57PM +0100, Seaborne, Andy wrote:
> 
> 
> 
> Eric Prud'hommeaux wrote:
> >I've changed 11.2.3.9 sop:datatype
> >  Returns a valid [RFC3066] language tag representing the XML schema
> >  language datatype for a variable.
> >to
> >  Returns the datatype of its argument if that argument is a typed
> >  literal. Otherwise it produces a type error.
> 
> In the case of a plain literal with no language tag, it would be natural to 
> return "", rather than an error.  This is akin to XML and avoids needing a 
> hasLang(..) operation.

The return type of datatype is supposed to be a URI. xsd:anyURI is
written in the table, but I have zero confidence that it distinquishes
between "http://example.com/" and <http://example.com/>.
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0415

However we spell <foo>, I don't think "" is one. I am comfortable
having datatype produce an error than have a variable return type.

> >and 11.2.3.8 sop:lang
> >  Returns a valid [RFC3066] language tag representing the XML schema
> >  language datatype for a variable.
> >to
> >  Returns an [RFC3066] language tag representing the XML schema
> >  language datatype of its argument if that argument has a language
> >  tag. Otherwise it produces a type error.
> 
> If it is going to be an error, then we should have hasDatatype().

I expect that the motivation is that one be able to safely invoke the
operator on wild data:
  FILTER (lang(?x) = "DE" || !hasLang(?x)

I propose that work out the DATATYPE case first, then see how much we
want LANG to be symmetrical with DATATYPE.

> [Not sure why the table entry is "SPARQL Casts" for these operations]

yeah, they don't seem to be casts, "SPARQL Accessors"?

> 	Andy
> 
> >
> >I used the lang change in langMatches:
> >  RFC3066 section 2.5 defines the language range '*' to match any
> >  tag. In SPARQL, the idiom langMatches( lang( ?v ), "*" ) will not
> >  match literals without a language tag as lang( ?v ) will produce a
> >  type error.
> >
> >
> >So basically, the argument for DATATYPE must be a typed literal, and
> >the argument to LANG must be a langed literal.
> >
> >
> >
> >
> >There is still more work to do on errors. For instance, Andy asked
> >what 1/0 is. XPath F&O has a large number of them[ERR], which we
> >implicitly use by defining our operators in terms of XPath functions.
> >
> >For instance, the Operator Mapping Table[OPS] ties '/' to
> >op:numeric-divide[DIV]. (This is inspired by XQuery's similar
> >construct somewhere near [QOP].)
> >
> >I think what's needed is some words about "errors" and "type errors"
> >and "other errors" derived from F&O.
> >
> >[ERR] http://www.w3.org/TR/2005/WD-xpath-functions-20050915/#d1e10985
> >[DIV] 
> >http://www.w3.org/TR/2005/WD-xpath-functions-20050915/#func-numeric-divide
> >[OPS] http://unagi/2001/sw/DataAccess/rq23/#OperatorMapping
> >[QOP] http://www.w3.org/TR/xquery/#dt-gregorian
> 

-- 
-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.