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

Re: Andy's review of the the protocol doc (part I)

From: Kendall Clark <kendall@monkeyfist.com>
Date: Thu, 4 Aug 2005 11:49:07 -0400
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20050804154907.GA3019@monkeyfist.com>

On Thu, Aug 04, 2005 at 04:35:17PM +0100, Seaborne, Andy wrote:

>     <xs:element name="malformed-query"></xs:element>
>     <xs:element name="query-request-refused"></xs:element>
>     <xs:element name="fault-details" type="xs:string"></xs:element>
> which is 3 one of which is called "fault-details"

I don't think that makes that element a fault message, though.

I really meant a schema for this kind of structure (and I realize the schema
above doesn't describe this):

<fault-details>blah, blah, blah</fault-details>

<fault-details>This query would kill our service. Go away.</fault-details>



Or, serialized in HTTP (some details wrong...):

HTTP/1.1 500 Internal Server Error
Date: Fri, 06 May 2005 20:55:12 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: text/plain

This query would kill our service. Go away.

I.e., I think we need a way to communicate fault messages optionally. I'll
get this sorted out.

> >Hmmm, not sure I understand yr point.
> Just that <_:abcd> is illegal as an IRI.  This MalformedQuery does not 
> allow much wiggle room for (non-standard) language extensions using the 
> protocol.  A SPARQL Protocol service MUST bounce illegal queries so can't 
> use the protocol with non-absolutely-correct-SPARQL queries which is what I 
> though UMD wanted.

Ah, good point. I guess that must can be a may or a should, then.

> "legal sequence of characters" can be read as "legal by the grammar" or 
> "legal by the grammar and any other rules that apply".

Yes, it can. I see at least two options:

1. redefine malformed query
2. leave the def'n as-is but change to should or may

Received on Thursday, 4 August 2005 15:51:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:48 UTC