Re: rq23 conformance section

On Sat, Nov 19, 2005 at 09:15:51PM -0600, Dan Connolly wrote:
> 
> 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.

Yeah, I said "I think I can" and I think I came up with a better
plan. If the issue is proceedural, then I can remove the text for
publication and this can wait for the next meeting.

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

I was trying to read this from the commentor's perspective, and the
perspective of people developing stuff for the SPARQL spec.
[[
A query is <em>successful</em> if it has been processed in accordance
with the semantics defined in this specification and the semantics
specified for any invoked extension functions.
]] is the only text that orients the reader as to how unimplemented 
extensions are handled. Also, I think the informative text that I
proposed is very useful.

I don't see how the protocol document is relevent to APIs. Are you
advocating that the protocol document be expanded to include APIs?

Keep in mind here, I'm not specifically trying to be a PITA; I'm
just trying to get as much interop on SPARQL as possible cheaply.

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