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