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

On Mon, Aug 15, 2005 at 12:07:22PM +0100, Steve Harris wrote:
> 
> 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.

Yep, the XSD, WSDL, and spec text are out of synch. I'm working on that
today.

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

Yeah, I'm not sure we need to re-document HTTP stuff. In fact, I've had
feedback that we should *not* do so, as in the case of con-neg. Not sure
what to do about this, frankly. Advice welcomed.

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

Sure. I'll drop the parens.

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

Thanks.

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

Yes. Doh.

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

That's part of the HTTP bindings description I've yet to finish writing.

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

Yes, I thought long and hard about this issue, finally deciding to return
the most generic 4 & 5 faults. I think there's language in the HTTP spec
about returning more specific ones, but I can't recall.

I'm pretty sure we could analogize lots of different HTTP faults to
different SPARQL cases, but I've tried to be minimalist. I guess I'd need to
hear more discussion or use cases for adding more faults.

(Though, in the case of 413, I may put some language in the spec about
returning it iff a service doesn't implement the query1 operation, that is,
the POST binding. That reinforces the idea that GET is to be preferred,
generally, to POST, except in cases of very large queries.)

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

Well, I think it should be a 5xx status code because it's the server that's
refusing the request, for *whatever reason*, and that doesn't mean it's
necessarily a client fault. In fact, it's probably not. It should be, IMO,
one of the 5xx faults.

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

It does mention that:

  Another possible source [of DOS attacks] are queries containing very
  complex -- either because of resource size, the number of resources to be
  retrieved, or a combination of size and number -- RDF dataset
  descriptions, 

Is that insufficient?

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

I don't get the part about similar text...

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

Instead of a less-specific identifier? Not sure how that's better.

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

What about HEAD requests? There's no operation in the abstract protocol that
binds to HEAD requests. Can you say more about this?

Thanks for the review, Steve!

Cheers, 
Kendall

Received on Monday, 15 August 2005 13:12:57 UTC