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

Review of http://www.w3.org/2001/sw/DataAccess/proto-wd/

From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
Date: Mon, 15 Aug 2005 12:07:22 +0100
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20050815110722.GF4129@login.ecs.soton.ac.uk>

Revision: 1.59, taking red text and @@s into account.

In "4. query Fault Messages" the WSDL fragments seem to differ from the
linked WSDL document
(http://www.w3.org/2001/sw/DataAccess/proto-wd/sparql-protocol-query.wsdl),
though could just be my lack of understanding of WSDL.

Also, I dont see an explanation of how do deal with other protocol level
faults (eg. client sends Accept: application/my-wacky-rdf-syntax), I guess
we fall back to sensible HTTP responses, but this could be made explict if
its the case. How does it apply to SOAP?

In "B. HTTP Examples" the parenthetical comments seem a bit long, and
important to be parenthesised. Minor issue.

In "c. CONSTRUCT with simple RDF dataset" the PREFIX URIs do not have thier
angle brackets escaped, so you see
PREFIX rdf: 
PREFIX foaf: 
PREFIX myfoaf: 

In "i. SELECT with malformed query fault", the Content-type is plain/text,
shouldn't it be text/plain?

The response code is "400 Bad Request", and the WSDL contains some
references to 400, but its not in the text. I would prefer it if the
response codes were specified in human-speak too, in section 4. Ditto for
the 500 in the next example.

I'm not clear on whether its allowed for the server to return more specific
errors where applicable, eg 413 Request Entity Too Large could be
appropriate in some cases.

"j. SELECT with query request refused fault", I'm not convinced that
500 is the most appropraite error. I can see the case for 403 Forbidden,
though its is also not neccesarily a perfect fit. From
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
"403 Forbidden. The server understood the request, but is refusing to
fulfill it. Authorization will not help and the request SHOULD NOT be
repeated. If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity."

"3. Policy Considerations", should also mention that the
default-graph-uri etc. parameters can cause multiple HTTP requests to be
issued in response to a single query request. This could make the SPARQL
protocol a vector for denial of service attacks - it both anonymises the
originator of the requests, and escalates the number of requests for a
small request cost. Needs some similar text to the direct DOS comments.

General comment. I'm not a fan of the sytle of incuding only the
most-specific subsection identifier. It make it hard to refer to sections.
Is this just for editing purposes? Minor issue.

How should HEAD requests be handled? This might be implicit in the WSDL,
but I'd like a line or two in the text.

- Steve
Received on Monday, 15 August 2005 11:08:31 GMT

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