08 Dec 2010

See also: IRC log





pgearon, going to join us?

<pgearon> coincidentally, I'm dialing now

<SteveH> can we have error message returns on the agenda? there was a lot of discussion on the list, but not recently

<pgearon> normal number?


code 772775

<kasei> :)




content of an update request


Abstractly, the contents of the In Message of SparqlProtocol's update operation is an

instance of an XML Schema complex type, called st:update-request, composed of one further

part: one SPARQL update string. The SPARQL update string,

identified by one update type, is defined by

[SPARQL] as "a sequence of characters in the language defined by the [SPARQLUpdate] grammar, starting with the SPARQLUpdate



<AndyS> AndyS: Issue: what does a client send for a SPARQL Update request? www-form or application/sparql-update and a body

http://sparql/endpoint?update=<contents of update request>

SteveH: 4store & 5store use POST form encoding

<AndyS> application/x-www-form-urlencoded vs application/sparql-update

<kasei> you can post to that, but the update= part isn't the post data.

LeeF: never an intention to do it over GET

<AndyS> You can mix and match : some in ?x=, some in body as x=

POST /uri



<AndyS> Fuseki uses request=

AndyS: if we put whttp:inputSerialization of application/sparql-update, can we POST the update request directly?

SteveH: we did it this way because it seemed easier for clients at the time

AndyS: depends on the client
... in ruby without extra gems, doing straight POST is easier
... if it's a form you can't stream a massive load straight into the database

LeeF: straight post of update request wouldn't allow other parameters

AndyS: other parameters could go in query string

LeeF: not sure how that works in WSDL specification

<kasei> I would like to see support for both.

<scribe> ACTION: Lee to look up how whttp:inputSerialization="application/sparql-update" would work and whether additional parameters could be included in the request URI query string [recorded in http://www.w3.org/2010/12/08-sparql-minutes.html#action01]

<trackbot> Created ACTION-341 - Look up how whttp:inputSerialization="application/sparql-update" would work and whether additional parameters could be included in the request URI query string [on Lee Feigenbaum - due 2010-12-15].

Other arguments in update protocol requests

<AndyS> USING and USING NAMED -- affect the WHERE part of an operation (not set whole request)

<pgearon> like LeeF, I expected we would have similar names in the protocol

<SteveH> me too

<SteveH> ...but we've not implemented it

LeeF: what do we do if WSDL does not give us a way to specify that one of the arguments (the update request string) get POSTed directly in the content body and the other two arguments get communicated in the query string

AndyS & SteveH: let's cross that bridge if/when we get to it

SteveH: concerned that mixing POST body content and query string parameters won't sit well with some systems
... concerned that will be tough with some server tool sets

<AndyS> RFC 3986 : Section 3 -> queryString is valid in any URI

LeeF: when this gets into the document, we can ask for implementor feedback on POSTing with body content and arguments in the parameters

response content


for update requests that succeed

200 response code?

no concept of update return values in SPARQL Update language

AndyS: fuseki returns text/plain with human-oriented success message
... 204 (no content)

<AndyS> Case 1 : form => 200 and text Case 2 : direct POST => 204

<pgearon> Mulgara (which has its own protocol for the moment), sends back 20x responses. If relevant, an extra header is added for extra info. (eg. triples inserted)

SteveH: we return 200 and text/plain content

<kasei> I'd be happy with SHOULD 200 with text/plain, allowing people to add more structured data and/or use other 2XX values if they have a good reason to...

What if we just say MUST return a 2xx response code

<SteveH> yup

<kasei> 202 is accepted

<kasei> 201 is created

<AndyS> HTTP spec says 200 or 204 for POST , also 201 and 303

<AndyS> Ahh - POST - 303 - GET design

<kasei> to avoid hitting reload causing problems

faults and error messages

<AndyS> Leef: can we not define anything specific, and suggest via examples?

<AndyS> (for SC to POST)

What explicit faults do we define? For each fault, what HTTP response code does it correspond with? How can error messages / error details be communicated?




1. Protocol specifies that error messages SHOULD be communicated in XHTML

2. Tha XHTML should contain the details of the error in a predictable place

2a. an element with a particular, well-known id="..."

2b. with RDFa

2c. with a particular class


<AndyS> "406 Not Acceptable" seems the one

-----> proposes extending SPARQL XML format

<SteveH> curl -I -H 'Accept: nonsuch/type' http://apache.org/

<SteveH> returns a 200, and some HTML

final message in thread - http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0035.html - suggests just getting text/plain errors

<AndyS> +1 to JSON-powered clients.

SteveH: Richard C's message seems to indicate that text/plain is the most common option

<pgearon> I'd like to see human text/plain for a human readable message, and optional X- headers for extra structured information

do nothing or suggest tex/tplain?

<kasei> leaning slightly towards doing nothing for fear of blocking future decisions.

<kasei> :|

<AndyS> RFC1867 HTTP file upload

<AndyS> http://tools.ietf.org/html/rfc5789

<SteveH> PATCH http://tools.ietf.org/html/rfc5789

<kasei> I think we should punt on this



the operation does not modify the resource identified by the Request-

URI in a predictable way, POST should be considered instead of PATCH

or PUT.


<kasei> oof

<kasei> you get the SD

pgearon: thinks PATCH is very good for sparql update over the protocol

general like of PATCH, extra status codes, etc.

general feeling that it might be too new for us to take up at this point in time

observation that PATCH requires atomicity

observation about lack of clarity around what the Request-URI is and how that affects appropriateness of PATCH

<kasei> yeah

SteveH: protocol document should point out that doing a GET on the endpoint gives you the SD

kasei: should be a SHOULD

SteveH: discourage people from doing backup/restore on the store by doing GET/PUT on the endpoint

<kasei> s/should be/is/ in the current SD document

Summary of Action Items

[NEW] ACTION: Lee to look up how whttp:inputSerialization="application/sparql-update" would work and whether additional parameters could be included in the request URI query string [recorded in http://www.w3.org/2010/12/08-sparql-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/12/08 17:46:11 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/should be/is/ in the current SD document
No ScribeNick specified.  Guessing ScribeNick: LeeF
Inferring Scribes: LeeF

WARNING: No "Present: ... " found!
Possibly Present: AndyS IPcaller LeeF SteveH karl kasei part pgearon trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 08 Dec 2010
Guessing minutes URL: http://www.w3.org/2010/12/08-sparql-minutes.html
People with action items: lee

[End of scribe.perl diagnostic output]