Re: preparation for next TC... please point me to unapproved test cases...

Axel,

Looking at
http://www.w3.org/2009/sparql/docs/tests/test-update.n3

it defines it's own :data and :graphData.  ut:data and ut:graphData but 
the doc uses the same as query qt:data and qt:graphData.

Are we using the same or different properties?

>> 2/ use of qt:query in update test - I have suggested use ut:request so
>> the range is not a query.
>
> I went back to use ut:query, ut:data, ut:graphData in the ut: namespace, see
> changes in [1] and
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010OctDec/0119.html

Why "ut:query"?  SPARQL Query and SPARQL Update are different languages 
(you can't mix queries and updates).

A query is something in SPARQL Query.
An update request is a sequence of update operations.  ut:request.

>> 3/ qt:data/qt:data for entailment tests
>>
>> I can't actually remember state of discussion - it's not used in the
>> entailment manifest currently AFAICS.
>
> I resolved this in the current version of the test case structure document, as
> we concluded in http://www.w3.org/2009/sparql/meeting/2010-08-03#line0088

that notes you were at the time going to capture more complex ones. Does 
this mean the testing format may yet change?

> see changes in [1].

>> 4/ Testing the 3 protocols (query, update, http)
>>
>> For update protocol, we seem to have mixed that into the manifest for
>> update tests. (e.g. "ut:result ut:success").  I'm not sure this is a
>> good idea.
>
> Hmmm, I see the point, but I don't have a better proposal at this stage.
> For the moment, I suggest to go forward with "ut:result ut:success", etc.
> unless someone has a better proposal (whereupon I'd be happy to fix/update affected test cases.


[[
it returns an error corresponding to the the value of the ut:result 
property, otherwise.
]]

http://www.w3.org/2009/sparql/docs/tests/test-update.n3
I found:
[[
:success a :Result;
   rdfs:comment "test shall pass without failure" .

:malformed-update  a :Result;
   rdfs:comment "test failure, cf. 
http://www.w3.org/TR/sparql11-protocol/#update-fault-messages" .

:graph-does-not-exist a :Result;
   rdfs:comment "test failure, cf. 
http://www.w3.org/TR/sparql11-protocol/#update-fault-messages" .
README.html
:graph-already-exists a :Result;
   rdfs:comment "test failure, cf. 
http://www.w3.org/TR/sparql11-protocol/#update-fault-messages" .

:update-request-refused a :Result;
   rdfs:comment "test failure, cf. 
http://www.w3.org/TR/sparql11-protocol/#update-fault-messages" .
]]

:malformed-update

unnecessary? shouldn't it be part of syntax testing?  And/or protocol? 
Simpler not to have bad syntax in functional test suite for update.

:graph-does-not-exist
:graph-already-exists

Not all stores will generate these.  Surely any test that uses them is 
not portable. CREATE, DROP non-SILENT are errors if a store so chooses 
but other stores may simply ignore them.

Is the plan to have one set of tests for all stores, aiming at the 
common ground for treatment of empty graphs, autocreation of graphs etc 
or is the intent to have different tests for different store types?

:update-request-refused

Under what conditions does a standalone update test generate this in a 
testable way?


Personally, I'd drop the error reporting unless there are universal 
errors.  Put it in syntax and protocol, as last time then have one set 
of tests all of which a compliant store should pass.



5/ Please can we not use ".rq" for updates. .rq is for queries.

.ru would be natural, or .su but it's not .sq.

Note we have to include a suggested extension in the MIME type 
registration so this isn't just internal to the WG.

	Andy

Received on Monday, 18 October 2010 08:44:29 UTC