Re: Representation header final proposal

On Jan 16, 2004, at 7:04 AM, Jacek Kopecky wrote:
>
> It's not surfacing a MIME part in the infoset, it's containing a
> resource representation in the infoset. In connection with XOP, the
> representation will be serialized as a MIME part, but that doesn't
> matter to the Representation header.
>
> If the original resource URI was dereferenced normally, HTTP would also
> put the representation as a (sorta) MIME entity on the wire, but apart
> from content-type and length, the other stuff is not significant to the
> application, I believe.

I disagree; while you might not have a use case for that, I'm unwilling 
to say that no one, in all time, will have a use for such metadata. In 
particular, entity metadata (i.e., that beginning with Content-) is 
often important to applications.

Let's look at it from a slightly different angle; why does this need to 
be standardised; why can't it be application-specific? The use case 
seems to be that URI resolvers can use it as a substitute mechanism for 
the dereference function, which has an expected output of a Web 
representation. If this structure isn't defined, that can't be done in 
an application-generic way.

So, this structure needs to model a Web representation for the benefit 
of the infrastructure (generic URI resolvers). A Web representation is 
data + metadata, not just data, and not just data + media type; it's 
completely legitimate for an application to want to know the 
Content-Language for a particular representation, for example. If that 
is only accommodated through an application-specific extension, the 
infrastructure that we're targeting for this -- URI resolvers -- won't 
know how to get that information. Therefore, we need to define a 
generic mechanism to make that metadata available that's compatible 
with the way that it's commonly exposed by URI resolver APIs.

Does that make sense, or am I misunderstanding something?

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems