Link to comment

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011May/0035.html

Status

Not yet sent.

Response

Ivan, thanks for the feedback, see the response (inline) below.

 > 1. Could the protocol be slightly tweaked so that PUT with multipart form is permitted for current "PUT" and "POST" functionality, 
 > in order to allow graph manipulation via trivial web page with "upload file" button? More common, should all operations be made 
 > available in that style, as an addition to the current functionality?

The editor's draft has been modified to accomodate this

 > 2. In case of HTTP PUT, what should happen if the submitted data are syntactically wrong? Should DROP SILENT GRAPH 
 > <graph_uri> or DROP SILENT DEFAULT be performed in any case? Should I keep the half-loaded data or DROP the partial 
 > result? Or I have no "faster" variants than 
 > - to parse everything and  cache in memory and change the storage only after the resource is parsed from beginning to end 
 >    (memory-consuming and memory-limited) or
 > - to make a "dry run" of the parser to check the syntax and then parse for the second time in order to make an actual job (2x slowdown).

Per 5.1 Status Codes, a 400 Bad Request response should be sent back.

 > 3. What should I do if authentication is required and graph-level security exists in the system if PUT or POST mentions relative 
 > IRI and the document contains more than one xml:base attribute? As a funny example, let odd xml:base-s be read-only and 
 > even xml:base-s be writeable for the active user.

Support for base resolution was removed prior to a recent publication due to situations where resolution was ambiguous .

 > 4. The spec says that "For operations involving an RDF payload (PUT and POST), the server MUST parse the RDF payload according 
 > to media type specified in the Content-Type header (if provided in the request). If this header is not provided, the server SHOULD 
 > attempt to parse the RDF payload as RDF/XML." If the Content-Type is not provided and I have a routine that guesses the type by 
 > the content of the resource and the routine reports that the resource is clearly Turtle and not RDF/XML in any way, should I load it 
 > as Turtle or blindly report an error?

A fallback heuristic for situations where content-type is not provided has been added to this section.

 > 5. Are there any requirements re. isolation? What should I do with conflicting PUTs or a HEAD/GET during PUT? DAV offers locking 
 > and version-checking functionality for very similar authoring and retrieval of remote resources, and that functionality is neither 
 > useless nor redundant, but graphs adds even more complications because they can be accessed even while being written, unlike most 
 > of DAV implementations.

Concurrency management is beyond the scope of this protocol and implementations should be able to do what they see fit to support concurrent access etc.

Chime, on behalf of the working group.