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

Hi Andy, 

thanks for the comments...

On 18 Oct 2010, at 05:43, Andy Seaborne wrote:

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

confused... ?Which doc?

> Are we using the same or different properties?

Different:

ut:data != qt:data and ut:graphData != qt:graphdata

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

My intention was:

ut:query = your ut:request != qt:query

...

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

... I see the pont, I changed that to ut:request...
for README.html, test-update.n3 and basic-update/

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

I hope not, at least not unless you want to model test cases where different 
entailment regimes are used for different graphs, but we need something to get going.

(BTW, I think we could just use sd:entailmentRegime for the Graph, as we had it earlier, it just restricts us to using the same entailment regime for the same graph all over the manifest, but that's not a severe restriction for test cases, in that way, so, even if we want this extended version of entailment tests, we don't need to change the current version, but just have to extend it later on.

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

I'd be ok with that. Do you mean to drop both ut:success and the error URIs so?

We need some volunteer to define tests/test structure for protocol?

> 
> 
> 5/ Please can we not use ".rq" for updates. .rq is for queries.
> 
> .ru would be natural, or .su but it's not .sq.

fair enough, I'd be ok with that.
> 
> Note we have to include a suggested extension in the MIME type
> registration so this isn't just internal to the WG.


Suggest to go through these comments in the call. Thanks for the review.

Axel
> 
>         Andy
>

Received on Monday, 18 October 2010 10:59:24 UTC