Re: [uriMediaType-9] New Internet Draft: Resrep Type

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