- From: Ivan Mikhailov <imikhailov@openlinksw.com>
- Date: Mon, 23 May 2011 16:10:36 +0700
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
Dear all, I've implemented the protocol in its current form, and as a result I've got a list of questions re. dealing with errors. 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? 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). 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. 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? 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. Thanks in advance for any suggestions/recommendations, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com
Received on Monday, 23 May 2011 09:11:01 UTC