- From: Mark Baker <distobj@acm.org>
- Date: Mon, 21 Mar 2005 17:31:00 -0500
- To: Kendall Clark <kendall@monkeyfist.com>
- Cc: public-rdf-dawg-comments@w3.org, algermissen@acm.org
Hi Kendall, On Mon, Mar 21, 2005 at 03:25:50PM -0500, Kendall Clark wrote: > On Tue, Feb 01, 2005 at 10:49:04AM -0500, Mark Baker wrote: > > > > Hi, > > > > This comment is submitted jointly by Mark Baker and Jan Algermissen, > > who discovered they had the exact same concern with the current spec[1]. > > Thanks a lot for reading it so carefully. My pleasure. It's important work. > > First, only one concrete protocol is provided (HTTP), which, in our > > opinion, doesn't exercise the abstract protocol sufficiently to give > > confidence that it can serve its intended purpose (see our fourth point > > below too). > > HTTP and SOAP bindings will be provided, eventually. Great! > > Third, we suggest that its inclusion may affect the interpretation of > > the concrete protocol. For example, a SPARQL protocol client may > > logically invoke GetGraph via HTTP GET and interpret a successful > > response to mean that GetGraph was invoked, which isn't an > > interpretation licensed by HTTP, nor reflected in the message in any > > way. > > In the present and in future drafts (at present, the draft is a bit > barren of prose), the SparqlGraphRetrieval interface (which is the > descendant of "GetGraph") may or may not be implemented by service > providers as they see fit. I look forward to seeing how that develops. > > Forth, and related to our first and third points, we believe that > > concrete protocols developed from the abstract protocol stand a good > > chance of being architecturally inconsistent with the systems formed > > by those protocols. For example, the abstract protocol would seem to > > suggest that a binding to SOAP would require operations called "Query", > > "GetGraph", and "GetServiceDescription". Yet, such an interpretation > > would be inconsistent with Web architecture when SOAP is used over > > HTTP. > > This seems more pertinent directed either to the SOAP or TAG folks. At > any rate, I'm pretty confident that the SOAP binding for SPARQL will > be sensitive to the issues raised by the WebArch doc -- at least, as > sensitive as a SOAP binding *can be*. > > In my personal view, not speaking for DAWG now, if there are problems > beyond that, they are SOAP, not SPARQL problems. But inquiring minds > may differ, I suppose. I hear you, and totally understand that position, but respectfully disagree. IMO, there's a lot of things - largely architectural - which are attributed to the SOAP specification which are not, in fact, licensed by it. But, without actually having a concrete binding proposal to discuss at this time, I'm sure you'd agree that it would be hard to have much in the way of a meaningful conversation on this point. So, I'm very much looking forward to a future draft with these bindings, and the opportunity to comment on them at that time. > Thanks for yr comments. My pleasure. Keep up the good work. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Monday, 21 March 2005 22:31:24 UTC