RE: Representation header final proposal

The TAG has said that a representation includes metadata (such as
media-type) of a representation. [1].  If people disagree with this, I
suggest they can send in Last Call comments on the Web arch document, or
this will become canon.

Cheers,
Dave

[1] http://www.w3.org/TR/webarch/#msg-representation

> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Mark Nottingham
> Sent: Wednesday, January 21, 2004 9:03 AM
> To: Yves Lafon
> Cc: Jacek Kopecky; XMLP Dist App
> Subject: Re: Representation header final proposal
>
>
>
> That makes sense, except that the majority of URI schemes that are
> dereferencable use a MIME or MIME-like metadata/data
> packaging; I'd put
> forth that from an infrastructure standpoint, there's no need to
> differentiate between these protocols.
>
> It's true that there are dereferencable URI schemes that return
> representations that aren't MIME-like, but my first guess
> would be that
> they'll all like file, with a semantic of "bag of bits." That
> fits into
> a MIME-like model (with no headers).
>
> If we really want to allow non-MIME-like, non-bag-of-bits
> representations, I could see making a "MIME-like protocols" extension.
>
> Cheers,
>
> P.S. What hath the TAG to say about the model (vs. form) of a
> representation? Can we just settle on MIME-like and be done with it?
>
>
> On Jan 21, 2004, at 5:03 AM, Yves Lafon wrote:
>
> > Well, that was the point of my proposal, however, Jacek's
> point (as I
> > understood it) is more:
> > * do a very raw thing
> > * extend to add extra information related to different protocols
> >
> > If we add <h:header> in the "HTTP" namespace, with all the necessary
> > information to act as a local cache, then I am happy, as long as we
> > don't
> > defer it to another spec.
> >
> >> If you don't want to send or use such metadata, that's your choice.
> >> However, if this mechanism is to be a drop-in replacement
> for the URI
> >> dereference function, I'd expect it to provide equivalent
> information
> >> when I need it. Otherwise, I don't see much point in the effort of
> >> standardising this header.
> >
> > What are the metadata for file: uri? Having a per-protocol extension
> > seems to be a good approach (we can even have family of
> protocol, as
> > some
> > share the same metadata schemes).
>
>

Received on Wednesday, 21 January 2004 12:19:34 UTC