W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2010

protocol issues and do we need a dedicated TC on them?

From: Axel Polleres <axel.polleres@deri.org>
Date: Tue, 27 Jul 2010 16:25:43 +0100
Message-Id: <897A8F01-E715-46E7-859E-DB32C2E31CA6@deri.org>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Here are the particular ISSUEs concerning protocol that I think we need to discuss 
separately (either in a dedicated TC or as separate item on one of the regular TCs).
It would be nice if we could discuss/extend this list on the mailinglist for a start.

best,
Axel

=======================================================================
ISSUE-22  Support of SOAP/WSDL in protocol for SPARQL/Update

see today's discussion, I gave an ACTION to Lee (who was only partially present, hope that's ok)
to add a note on dropping of SOAP binding to next WD of protocol11 and explicitly solicit 
feedback on usage of SOAP in SPARQL. It seems that this dropping was not formally mentioned in 
any changelog or feedback asked for, which raised some concerns today.
=======================================================================
ISSUE-33 Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL?

The only thing I realize at the moment is that this ISSUE is not even mentioned in the protocol draft. Shall we mention/explain it?
We have some errors in protocol listed, which more do we need?

=======================================================================
ISSUE-58 Register a MIME type for SPARQL Update requests?

Andy:
Yes please.
Lee:
Perhaps we can get an action on our team contacts to take responsibility
for this?

=======================================================================

More ISSUEs not yet listed? 

=======================================================================
ISSUE-A: concrete result format of update

=======================================================================
ISSUE-B: Where do we (need to) say something about transactionality?

We have closed the ISSUES regarding transactionality, but - WHERE do we mention
the conclusion of this discussion, I suggest to add an appendix "Transactionality/Concurrency" to protocol noting:

"Any compliant SPARQL1.1 implementation SHOULD treat every (HTTP) request atomically. SPARQL1.1 does not specify any further 
 restrictions regarding transactionality and concurrency, although specific implementations may satisfy stronger guarantees."

=======================================================================
Received on Tuesday, 27 July 2010 15:26:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:43 GMT