Re: Summary of comments on HTTP-in-RDF

Shadi Abou-Zahra schrieb:
> 0. clarify the scope of the vocabulary
> -> it seems we need to add some text to the document to better explain
> the scope of this vocabulary, I suggest somewhere in section 1.

ACK

> 1. represent when a request fails
> -> tentative response: out of scope for HTTP-in-RDF.

ACK

> 2. timestamp requests and responses
> -> need to decide whether to implement this or not. It seems pretty easy
> and useful to add dc:date properties to the response/request classes.

Everyone who needs it can add dc:date properties to request/response. 
There's no need for us to allow/disallow it.

> 3. extension mechanism in HTTP for the request
> -> tentative response: subclass and extend the request class.

ACK

> 4. both the absolute and the relative URI
> -> tentative response: out of scope for HTTP-in-RDF.

ACK

> 5. normalisation of header field values
> -> need to define some form of convention, even if no transformation is
> done we need to say that somewhere. What convention do we want to use?
> 
> 5.a. literal representation of the unprocessed headers
> -> need to decide whether to implement this or not. It seems pretty easy
> to add an "http:transcript" property to store the original header text.

I don't think we need a literal representation of the unprocessed 
headers, if the processed representation of the headers is equivalent to 
the unprocessed stuff.

> 6. header field exposed in a way that allows easy access via XPATH
> -> need to decide whether to implement this or not, it seems however out
> of scope and not straight forward to do.

See <http://lists.w3.org/Archives/Public/public-wai-ert/2007Mar/0071.html>

> 7. two different representations for headers
> -> we need to consider if we want a single mechanism to provide headers
> (see response from Johannes on issue #5 in Jo's comments).

Or see 
<http://lists.w3.org/Archives/Public/public-wai-ert/2007Mar/0071.html>

> 8. provide a linkage between a response and a request
> -> tentative response: out of scope for HTTP-in-RDF.

ACK

> 9. algorithm for representation of the body
> -> need to refine the algorithm a little more. I propose to add
> *wellformed XML* to better explain what we mean, and clarify that the
> "use plain literal" step includes escaping special characters.

ACK

> 10. provide mechanism for extensible response code
> -> need to decide whether to implement this or not. Would need some
> reworking but seems useful and good practice to do.

Yes, HTTP allows this. See production rule for Status-Code in 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1>.

> 11. record the size of the headers and the body
> -> tentative response: out of scope for HTTP-in-RDF.

ACK

> 12. the order of the requests in connection class
> -> need to decide whether (and how) to implement this. We need to
> specify an rdf:Seq list but not sure how to do this in RDFS.

I'm not sure whether you can do this in RDFS.

Just use

<http:request>
   <rdf:Seq>
     <rdf:li>
       <rdf:Request rdf:ID="req1">
         ...
       </rdf:Request>
     </rdf:li>
     <rdf:li>
       <rdf:Request rdf:ID="req2">
         ...
       </rdf:Request>
     </rdf:li>
   </rdf:Seq>
</http:request>

or

<http:request rdf:parseType="Collection">
   <rdf:Request rdf:ID="req1">
     ...
   </rdf:Request>
   <rdf:Request rdf:ID="req2">
     ...
   </rdf:Request>
</http:request>

-- 
Johannes Koch
BIKA Web Compliance Center - Fraunhofer FIT
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065

Received on Monday, 19 March 2007 15:07:35 UTC