Re: rq23 conformance section

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?

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

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

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

> >>>http://www.w3.org/2001/sw/DataAccess/rq23/#conformance

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