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

Re: 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 15:27:27 +0100
To: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20050815142727.GB22126@login.ecs.soton.ac.uk>

On Mon, Aug 15, 2005 at 10:07:07AM -0400, Kendall Clark wrote:
> 
> On Mon, Aug 15, 2005 at 02:46:39PM +0100, Steve Harris wrote:
> 
> > > 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.
> > 
> > I dont know about the WSDL mechanics, but a line like "for other fault
> > conditions use HTTP error responses as appropriate [ref]" would have done
> > fine - if thats the intention. 
> 
> But we're only documenting two fault conditions, MalformedQuery and
> QueryRequestRefused, so I'm not sure what it would mean to say "other fault
> conditions" specific to SPARQL Protocol. There are, of course, other
> conditions, but I think if we care enough to say that you can "just use HTTP
> for them", then we should define them in the spec.

I suspect I chose the wrong wording. No matter how extensivly we define
the possible responses someone will come up with something really wacky, I
think it would be good to have a getout cluase giving people an indication
of how to do something sensible. Unless you want all legal responses to be
enumerated in the spec, which would also be reasonable.
 
> > > 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.
> > 
> > True, but equally its refusing it because of something the client has
> > done. 
> 
> But not something that the client has done that's a *fault* or error, right?

Well, no more so than doing something which would cause a 403 error on a
webserver (its still a valid HTTP request, it just happens to be to a
resource that the server doesnt want to return). Its possible for the
server to satisfy the request, but it has chosen not to.

> The client asking the server to retrieve the World's Largest RDF Graph and
> do a very complex query upon it is perfectly legal, it's just not sane. :>
> 
> I do think this is a bit of coin toss, and now we've at least discussed it
> some.

Sure. I'm content with 500, I just thought I'd mention that its not the
only candidate. To me 500 Internal Server Error signifies that something
bad has happened in the server, whereas in this case its made a decision
to to comply - though the wording in the RFC is much more broad.
 
> > I just wondered whats suposed to happen if you present a sparql service
> > with a HEAD request (ditto PUT, META or whatever).
> 
> That's undefined intentionally in the present design. Previous versions of
> the protocol design did interesting (in the opinions of some, anyway) with
> other HTTP methods, but those versions failed to gain much support. Alas. :>

OK, seems reaonable. It means that thier meaning can be defined later.

- Steve
Received on Monday, 15 August 2005 14:29:08 GMT

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