Re: Representation header final proposal

Mark, 

I think I was replying to how I thought you wanted all the content-
headers (and other headers) that may be in the Representation header to
be present in the XOP MIME part carrying the content. I posit it's
unnecessary but may be nice.

I think you're arguing below that Representation header needs to be able
to carry all the additional headers (apart from media type). My proposal
shows how such functionality can be layered on top of the simple
Representation header (by extension) and if the group agrees, we shall
produce such an extension.

As for "defining a generic mechanism to make that metadata available
that's compatible with the way that it's commonly exposed by URI
resolver APIs" - the API I commonly use in my applications gets a URI
and gives me a stream of octets, I seldom even care about the media
type, I just expect it to be the right thing for my application. I don't
know what's common in general, tho. 8-)

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/








On Sat, 2004-01-17 at 04:30, Mark Nottingham wrote:
> 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
>

Received on Monday, 19 January 2004 08:53:48 UTC