- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Tue, 10 Jan 2006 13:36:36 -0500
- To: andy.seaborne@hp.com
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Jan 10, 2006, at 1:01 PM, Seaborne, Andy wrote: > Other than what? I am just reading the spec and making an > interpretation. I'm not advocating a design change. I believe that changing must to should changes the design. One easy way to solve this: if the WG agrees with you and wants should, I'll change it immediately. The problem is we are the only ones who seem to care about this, and I don't agree with you. >> because I have no more confidence that I'm going to convince you >> than you probably have of convincing me. Or, put another way, I'm >> very unlikely to be convinced of yr position, at least not w/out >> something new. > > It is clear that you will not change the document. I don't think that's especially fair or charitable. I said I wasn't likely to be convinced by yr reading. And it's clear that I'll change the document if or when the WG says that's the design it wants. Or, if or when you convince me. Let's see how much we can agree on. I think: 1. In HTTP bindings WSDL faults are serialized by (hence: constrain the meaning of) particular HTTP status codes 2. Hence, our design constrains the meaning of 400 and 500. 3. Implementers are free, given the text of WSDL and the HTTP spec, to return any other HTTP status code in any situation warranted by the meaning of the HTTP spec 4. If a service returns any HTTP status code other than 400 or 500, it's isn't actually returning a WSDL fault at all. 5. If a service receives a request with an illegal SPARQL query string, it should return MalformedQuery (hence: 400) and must not return 2xx. 6. If a service receives a request it refuses to process, it must return QueryRequestRefused (hence: 500). 7. If a service, or any intermediate host, returns any HTTP status code other than 400 or 500, it has not returned a WSDL fault at all. 8. Our spec shouldn't constrain what other HTTP status codes can be returned, because HTTP spec already covers this. 9. The two WSDL faults we've defined apply (equally!) to SOAP and to HTTP bindings. Seems to me that the only thing we actually disagree about is what "refuses" in (6) means. You take it very broadly; basically, everything but MalformedQuery is the service refusing to process. I don't take it that broadly. That means, I think, that we either need to make "refuses" more explicit, which we can do in many ways, or to redefine the fault completely, or to drop it. Cheers, Kendall -- You're part of the human race All of the stars and the outer space Part of the system again
Received on Tuesday, 10 January 2006 18:36:45 UTC