- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 24 Oct 2006 00:29:13 +0200
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Sat, Oct 21, 2006 at 05:23:26PM +0100, Seaborne, Andy wrote:
>
>
>
> Eric Prud'hommeaux wrote:
> >On Thu, Aug 24, 2006 at 09:45:33PM +0100, Seaborne, Andy wrote:
> >>"""
> >>ACTION AndyS:
> >>Write some tests for value testing (unknown types and extensibility) to
> >>add to
> >>2006/JulSep0086
> >>"""
> >>
> >>http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JulSep/0086
> >>http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0104
> >>
> ...
> >
> >Of these, I only passed date-4, which does not require any extension
> >to the SPARQL language as specified.
> >date-1:
> > passed: "2006-08-23"^^xsd:date = "2006-08-23"^^xsd:date
> > failed: "2006-08-23Z"^^xsd:date = "2006-08-23"^^xsd:date
> > failed: "2006-08-23+00:00"^^xsd:date = "2006-08-23"^^xsd:date
> >
> >date-2:
> > failed: "2006-08-23"^^xsd:date != "2006-08-23"^^xsd:date
>
> That could be passed even for a processor that does not understand
> xsd:date? Because these are the same term (date-1/passed) then they
> evaluate != to false since the same lexical forms means same value hence
> != is know to be false for any datatype, known or unknown.
>
> > failed: "2006-08-23Z"^^xsd:date != "2006-08-23"^^xsd:date
> > failed: "2006-08-23+00:00"^^xsd:date != "2006-08-23"^^xsd:date
> >
> >date-3:
> > failed: "2006-08-23"^^xsd:date > "2006-08-22"^^xsd:date
> > failed: "2006-08-23Z"^^xsd:date > "2006-08-22"^^xsd:date
> > failed: "2006-08-23+00:00"^^xsd:date > "2006-08-22"^^xsd:date
> >
> >date-4:
> > passed: datatype("2006-08-23"^^xsd:date ) = xsd:date
> > passed: datatype("2006-08-24Z"^^xsd:date) = xsd:date
> > passed: datatype("2000-01-01"^^xsd:date ) = xsd:date
> >
> >These tests bring up the issue of how we test extensions. I think all
> >we can do is test the bare language, writing tests that appear to
> >label an extended implementation as "failed".
>
> Right - these tests were written to capture "="/"!=" on both known and
> unknown types, and what happens when an extension datatype is known. Not
> all the tests will be appropriate in the code DAWG test suite.
>
> For testing extensions, how about separating the tests out into a separate
> area? At least, have different manifest files so that an implementation
> can pick up the manifests and run the appropriate ones.
I prefer labeling these tests in the manifest, ala:
[ mf:name "date-1" ;
rdfs:comment "Added type : xsd:date '='" ;
mf:action
[ qt:query <date-1.rq> ;
qt:data <data-3.ttl> ] ;
mf:result <date-1-result.srx> ;
mf:requires xsd:date
The semantics of mf:requires are that it can be an xsd type, in which
case, you need support for that type to get those results. If it's
something else, you just need special code to handle whatever it
is. For example,
mf:requires geo:distance
could correspond to a sadl:supports that says which extensions the
server supports.
--
-eric
home-office: +1.617.395.1213 (usually 900-2300 CET)
+33.1.45.35.62.14
cell: +33.6.73.84.87.26
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Monday, 23 October 2006 22:28:18 UTC