15:57:03 <RRSAgent> RRSAgent has joined #sparql
15:57:03 <RRSAgent> logging to http://www.w3.org/2010/12/08-sparql-irc
15:57:08 <LeeF> zakim, room for 6?
15:57:10 <Zakim> ok, LeeF; conference Team_(sparql)15:57Z scheduled with code 772775 (SPARQL) for 60 minutes until 1657Z
15:57:20 <LeeF> rrsagent, make logs world
15:57:22 <LeeF> thanks
15:57:39 <Zakim> Team_(sparql)15:57Z has now started
15:57:46 <Zakim> +SteveH
15:57:49 <Zakim> +LeeF
15:58:30 <Zakim> +kasei
15:58:35 <Zakim> +[IPcaller]
15:58:44 <AndyS> zakim, IPcaller is me
15:58:44 <Zakim> +AndyS; got it
15:58:48 <LeeF> pgearon, going to join us?
15:59:22 <pgearon> coincidentally, I'm dialing now
15:59:26 <SteveH> can we have error message returns on the agenda? there was a lot of discussion on the list, but not recently
15:59:34 <pgearon> normal number?
15:59:37 <LeeF> yup
15:59:39 <LeeF> code 772775
16:00:04 <Zakim> +pgearon
16:02:11 <kasei> Zakim, pick an editor
16:02:11 <Zakim> I don't understand 'pick an editor', kasei
16:02:12 <kasei> :)
16:02:18 <LeeF>  :D
16:03:51 <LeeF> http://www.w3.org/2009/sparql/docs/protocol-1.1/
16:03:52 <LeeF> http://www.w3.org/2009/sparql/docs/protocol-1.1/#update-operation
16:04:33 <LeeF> topic: content of an update request
16:04:39 <LeeF> """
16:04:40 <LeeF> Abstractly, the contents of the In Message of SparqlProtocol's update operation is an
16:04:40 <LeeF> instance of an XML Schema complex type, called st:update-request, composed of one further
16:04:40 <LeeF> part: one SPARQL update string. The SPARQL update string,
16:04:40 <LeeF> identified by one update type, is defined by
16:04:40 <LeeF> [SPARQL] as "a sequence of characters in the language defined by the [SPARQLUpdate] grammar, starting with the SPARQLUpdate
16:04:43 <LeeF> production".
16:04:44 <LeeF> """
16:04:50 <AndyS> AndyS: Issue: what does a client send for a SPARQL Update request?  www-form or application/sparql-update and a body
16:05:58 <LeeF> http://sparql/endpoint?update=<contents of update request>
16:06:20 <SteveH> q+
16:06:35 <LeeF> ack SteveH
16:06:53 <LeeF> SteveH: 4store & 5store use POST form encoding
16:07:26 <AndyS> application/x-www-form-urlencoded   vs   application/sparql-update
16:07:27 <kasei> you can post to that, but the update= part isn't the post data.
16:08:13 <LeeF> LeeF: never an intention to do it over GET
16:08:18 <AndyS> You can mix and match : some in ?x=,  some in body as x=
16:08:29 <LeeF> POST /uri
16:08:29 <LeeF> ...
16:08:34 <LeeF> update=.....
16:09:23 <AndyS> Fuseki uses request=
16:11:41 <LeeF> AndyS: if we put whttp:inputSerialization of application/sparql-update, can we POST the update request directly?
16:12:14 <LeeF> SteveH: we did it this way because it seemed easier for clients at the time
16:12:18 <LeeF> AndyS: depends on the client
16:12:27 <LeeF> ... in ruby without extra gems, doing straight POST is easier
16:14:45 <LeeF> AndyS: if it's a form you can't stream a massive load straight into the database
16:15:05 <LeeF> LeeF: straight post of update request wouldn't allow other parameters
16:15:10 <LeeF> AndyS: other parameters could go in query string
16:15:16 <LeeF> LeeF: not sure how that works in WSDL specification
16:17:24 <kasei> I would like to see support for both.
16:23:45 <LeeF> 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
16:23:46 <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].
16:25:00 <LeeF> topic: Other arguments in update protocol requests
16:25:29 <AndyS> USING and USING NAMED -- affect the WHERE part of an operation (not set whole request)
16:25:45 <pgearon> like LeeF, I expected we would have similar names in the protocol
16:25:57 <SteveH> me too
16:26:11 <SteveH> ...but we've not implemented it
16:27:02 <karl> karl has joined #sparql
16:33:43 <LeeF> 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
16:33:55 <LeeF> AndyS & SteveH: let's cross that bridge if/when we get to it
16:34:18 <LeeF> SteveH: concerned that mixing POST body content and query string parameters won't sit well with some systems
16:34:56 <LeeF> SteveH: concerned that will be tough with some server tool sets
16:35:51 <AndyS> RFC 3986 : Section 3 -> queryString is valid in any URI
16:36:13 <LeeF> LeeF: when this gets into the document, we can ask for implementor feedback on POSTing with body content and arguments in the parameters
16:38:34 <LeeF> topic: response content 
16:38:59 <LeeF> http://www.w3.org/2009/sparql/track/issues/60
16:39:13 <LeeF> for update requests that succeed
16:39:28 <LeeF> 200 response code?
16:40:21 <LeeF> no concept of update return values in SPARQL Update language
16:40:33 <LeeF> AndyS: fuseki returns text/plain with human-oriented success message
16:41:05 <LeeF> ... 204 (no content)
16:41:30 <AndyS> Case 1 : form => 200 and text Case 2 : direct POST => 204
16:41:36 <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)
16:43:06 <LeeF> SteveH: we return 200 and text/plain content
16:44:29 <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...
16:46:52 <LeeF> What if we just say MUST return a 2xx response code
16:47:08 <SteveH> yup
16:48:49 <kasei> 202 is accepted
16:48:52 <kasei> 201 is created
16:50:28 <AndyS> HTTP spec says 200 or 204 for POST , also 201 and 303
16:50:52 <AndyS> Ahh - POST - 303 - GET design
16:51:21 <kasei> to avoid hitting reload causing problems
16:55:09 <LeeF> topic: faults and error messages
16:55:14 <AndyS> Leef: can we not define anything specific, and suggest via examples?
16:55:24 <AndyS> (for SC to POST)
16:55:51 <LeeF> 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?
17:01:05 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Sep/0002.html
17:01:46 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0011.html
17:03:24 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0009.html
17:04:54 <LeeF> 1. Protocol specifies that error messages SHOULD be communicated in XHTML 
17:05:09 <LeeF> 2. Tha XHTML should contain the details of the error in a predictable place
17:05:21 <LeeF> 2a. an element with a particular, well-known id="..."
17:05:26 <LeeF> 2b. with RDFa 
17:05:30 <LeeF> 2c. with a particular class
17:08:33 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0023.html
17:08:39 <AndyS> "406 Not Acceptable" seems the one 
17:08:40 <LeeF> -----> proposes extending SPARQL XML format
17:10:59 <SteveH> curl -I -H 'Accept: nonsuch/type' http://apache.org/
17:11:04 <SteveH> returns a 200, and some HTML
17:13:06 <LeeF> final message in thread - http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0035.html - suggests just getting text/plain errors
17:20:24 <AndyS> +1 to JSON-powered clients.
17:20:50 <LeeF> SteveH: Richard C's message seems to indicate that text/plain is the most common option
17:21:54 <pgearon> I'd like to see human text/plain for a human readable message, and optional X- headers for extra structured information
17:21:55 <LeeF> do nothing or suggest tex/tplain?
17:22:05 <kasei> leaning slightly towards doing nothing for fear of blocking future decisions.
17:22:28 <kasei> :|
17:28:07 <AndyS> RFC1867 HTTP file upload
17:33:58 <AndyS> http://tools.ietf.org/html/rfc5789
17:34:41 <SteveH> PATCH http://tools.ietf.org/html/rfc5789
17:36:07 <kasei> I think we should punt on this
17:37:05 <LeeF> """
17:37:06 <LeeF> If
17:37:06 <LeeF>    the operation does not modify the resource identified by the Request-
17:37:06 <LeeF>    URI in a predictable way, POST should be considered instead of PATCH
17:37:06 <LeeF>    or PUT.
17:37:07 <LeeF> """
17:37:26 <kasei> oof
17:38:28 <kasei> you get the SD
17:40:48 <LeeF> pgearon: thinks PATCH is very good for sparql update over the protocol
17:40:56 <LeeF> general like of PATCH, extra status codes, etc.
17:41:05 <LeeF> general feeling that it might be too new for us to take up at this point in time
17:41:13 <LeeF> observation that PATCH requires atomicity
17:41:31 <LeeF> observation about lack of clarity around what the Request-URI is and how that affects appropriateness of PATCH
17:42:05 <kasei> yeah
17:42:08 <LeeF> SteveH: protocol document should point out that doing a GET on the endpoint gives you the SD
17:43:37 <LeeF> kasei: should be a SHOULD
17:44:07 <LeeF> SteveH: discourage people from doing backup/restore on the store by doing GET/PUT on the endpoint
17:44:12 <kasei> s/should be/is/ in the current SD document
17:45:59 <Zakim> -LeeF
17:46:01 <Zakim> -SteveH
17:46:02 <Zakim> -pgearon
17:46:06 <LeeF> RRSAgent, make minutes
17:46:06 <RRSAgent> I have made the request to generate http://www.w3.org/2010/12/08-sparql-minutes.html LeeF
17:46:10 <Zakim> -AndyS
17:46:13 <Zakim> -kasei
17:46:14 <Zakim> Team_(sparql)15:57Z has ended
17:46:15 <Zakim> Attendees were SteveH, LeeF, kasei, AndyS, pgearon
17:46:28 <LeeF> RRSAgent, make minutes public
17:46:28 <RRSAgent> I'm logging. I don't understand 'make minutes public', LeeF.  Try /msg RRSAgent help
17:46:32 <LeeF> RRSAgent, make logs world
18:08:53 <Zakim> Zakim has left #sparql