- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 17 Dec 2009 08:13:21 -0500
- To: public-earl10-comments@w3.org
(bcc: AWWSW TF <public-awwsw@w3.org> ) I'm sorry I wasn't aware of the November 30 deadline, but as the document is not in last call I thought I would send along some comments anyhow. I would like to suggest that the vocabulary include some treatment of HTTP entities. This would be useful in validating cache and proxy correctness, for example in accounting for the 'etag' header. It would also be useful to the TAG in some of its ontology work, and I believe in many other applications. You could, for example, have an Entity class. Each Entity would have a subset of the information carried in some Message; there would have to be a property that related an Entity to a Message, similar to 'part of'. The MessageHeaders of an Entity would only include entity-headers, not request-headers. For minimum disruption to what you have so far Entity could be made a subclass of Message, which I think would be OK (i.e. an Entity is a Message that has no headers that are not entity-headers). A more principled approach would be to have a common superclass of Message and Entity, but I don't know what you'd call that class. Probably many other designs are possible, such as having no common superclass and a disjoint suite of properties for the two. -- some minor points: May I suggest that using the namespace prefix 'http:' is a bit confusing. It is technically correct but is very distracting because of dissonance with the 'http:' URI scheme prefix. I would suggest something like 'ht:' or 'htp:' or 'hvr:' instead. I find it odd that while most of the spec uses camelCase, 'abs_path' uses an underscore. May I suggest calling it 'absolutePath'. Best Jonathan
Received on Thursday, 17 December 2009 14:07:45 UTC