W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2004

Re: Representation header final proposal

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Wed, 21 Jan 2004 09:02:54 -0800
Message-Id: <A74376A2-4C33-11D8-97B0-00039396E15A@bea.com>
Cc: Jacek Kopecky <jacek.kopecky@systinet.com>, XMLP Dist App <xml-dist-app@w3.org>
To: Yves Lafon <ylafon@w3.org>

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.


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:03:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:25 UTC