W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

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

From: Sean B. Palmer <sean@mysterylights.com>
Date: Wed, 27 Mar 2002 20:50:48 -0000
Message-ID: <025a01c1d5d1$15bbe0c0$ceb90150@localhost>
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:50 UTC