See also: IRC log
thanks
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?
yup
code 772775
<kasei> :)
:D
http://www.w3.org/2009/sparql/docs/protocol-1.1/
http://www.w3.org/2009/sparql/docs/protocol-1.1/#update-operation
"""
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
production".
"""
<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
scribe:
update=.....
<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].
<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
http://www.w3.org/2009/sparql/track/issues/60
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
<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?
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Sep/0002.html
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0011.html
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0009.html
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
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0023.html
<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
"""
If
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
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]