Re: rq23 conformance section

On Sat, 2005-11-19 at 18:53 -0500, Eric Prud'hommeaux wrote:
> On Sat, Nov 19, 2005 at 02:32:41PM -0500, Dan Connolly wrote:
> > 
> > On Nov 19, 2005, at 1:45 PM, Eric Prud'hommeaux wrote:
> > 
> > >On Sat, Nov 12, 2005 at 12:49:54PM -0600, Dan Connolly wrote:
> > >>
> > >>On Sat, 2005-11-12 at 11:39 -0500, Eric Prud'hommeaux wrote:
> > >>>[[
> > >>>The grammar in appendix A defines the syntax of SPARQL Queries.
> > >>
> > >>SPARQL Query strings, no?
> > >>
> > >>(broken link to "grammar", btw")
> > >>
> > >>> Apart
> > >>>from extension functions, the semantics of all SPARQL Queries are
> > >>>defined within this document. A query is successful if it has been
> > >>>processed in accordance with the semantics defined in this
> > >>>specification and the semantics specified for any invoked extension
> > >>>functions.
> > >>
> > >>I don't see why introduce a notion of "successful"; it's clearly
> > >>not a property of queries. The same query might be "successful"
> > >>in one case and not in another.
> > >
> > >This definition of query sounds more like a query string. SPARQL
> > >queries have semantics and results. Success/failure seems implicit
> > >in that.
> > 
> > Nothing about semantics nor results depends on how it's processed.
> > 2+2 is 4 whether your calculator is working or not.
> 
> Nice analogy. It shows that the query doesn't have to have success,
> However, what's the cost to having a rule that any implementations of
> query associate a lack of success with malformed queries or queries
> with unsupported extensions?

The cost is in adding the concept of "implementation of query"
to the scope of the spec. Your action was to make an editorial
change to re-arrange stuff that's already in the spec, not
to add a new class of product.


> > We have a definition of SPARQL query
> >  http://www.w3.org/2001/sw/DataAccess/rq23/#defn_SPARQLquery
> > and results
> >  http://www.w3.org/2001/sw/DataAccess/rq23/#defn_ResultForm
> > 
> > I can only see 2 notions of 'successful': one that's totally redundant
> > w.r.t. those 2 definitions, and one that relates an implementation
> > or an execution of a query, which is out of the scope we have
> > established for the QL spec.
> > 
> > >If someone writes a SPARQL Query over SMTP protocol, they MUST
> > >create tell the requestor if the query succeeded. SPARQL Protocol
> > >uses the SPARQL Query Results Format but I don't expect all APIs
> > >and protocols will.
> > 
> > All APIs are either concrete versions of our abstract protocol, or 
> > they're out of scope.
> 
> Out of scope for the WG or the QL? Care to back that up?

Out of the scope that the WG decided, by going to last call,
that the spec would cover. Again, we discussed rearranging this
conformance text as an editorial change, not a design change.

> > The protocol is specified in terms of the results format schema, but 
> > you can
> > take that as an abstract definition of what comes back. Or you could 
> > propose
> > that we add some 'or equivalent expression' language to the protocol 
> > document.
> 
> This seems relevent to protocol conformance, not query.

Quite.

But I understand you to argue that judging correct execution
should somehow get introduced into the QL spec.

> > > I think success/failure is a reasonable low
> > >bar for conformance.
> > >
> > >>I think this should do:
> > >>
> > >>
> > >>  B. Conformance
> > >>
> > >>  See appendix A grammar regarding conformance of _SPARQL
> > >>  Query strings_, and section 10 Query Result Forms for
> > >>  conformance of query results. See appendix E. Internet Media Type
> > >>  for conformance to the application/sparql-query media type.
> > >>
> > >>  This specification is intended for use in conjuction with
> > >>  the SPARQL Protocol[SPROT] and the
> > >>  SPARQL Query Results XML Format[RESULTS]. See those specifications
> > >>  for their conformance criteria.
> > >
> > >I'd much prefer that this conformance section be relevent to folks
> > >developing APIs (which I expect to be numerous) and protocols (which
> > >will probably be less numerous).
> > 
> > Why?
> > 
> > In earlier discussions, we have talked about how APIs and command-line
> > interfaces are isomorphic to our WSDL abstract protocol. Why
> > the switch now?
> 
> This conformance text is for query, not protocol.

Yes, I understand that to be your proposal. My question stands: *why*
do you want to put API conformance in the QL spec, when it's
already covered by the protocol spec?

> > >>>http://www.w3.org/2001/sw/DataAccess/rq23/#conformance
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Sunday, 20 November 2005 03:16:18 UTC