- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Wed, 27 Mar 2002 20:50:48 -0000
- To: "Graham Klyne" <GK@NineByNine.org>, "Mark Baker" <distobj@acm.org>
- Cc: <www-tag@w3.org>
Hi Mark, Graham, > Perhaps Repr-Type could used a feature tag, but > Resource-Type cannot because it is not an attribute > of the content, it is an attribute of the resource that > the URI identifies. Absolutely: Resource-Type as proposed can't be a Content-features header. However, you can chain properties to form a *new* relationship that would be a valid attribute of the content:- [ :reprOf [ :resourceType :Person ] ] . I.e. "there is something that is the representation of something else that has the resource type (analogous to rdf:type) of :Person". I'm not sure how useful that would be; it would require a use-case scenario to merit coming up with yet-another-new-property! OTOH, "Repr-Type" for Content-features is an interesting prospect. Graham, you listed one of the advantages as "administratively and politically easier to achieve", but I actually can't work out what the registration process for new headers is from the RFC. I presume that they're just defined in RFCs, as for any normal HTTP header, so why would registering it as a content-feature header be a path of less resistance? Working harmoniously with the IETF conneg/W3C CC/PP work is also another benefit, but can you guarantee that the groups have bought into using Content-features? Not that you have to sell it to me or anything :-) It would be great to set up something where the user agent requests "anything, as long as it's XML", and the server works out that it's canonicalized XML variant is a subClassOf XML, and therefore it can send it. -- Kindest Regards, Sean B. Palmer @prefix : <http://purl.org/net/swn#> . :Sean :homepage <http://purl.org/net/sbp/> .
Received on Wednesday, 27 March 2002 15:51:34 UTC