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: Tue, 20 Jan 2004 14:17:28 -0800
Message-Id: <6EB9FE87-4B96-11D8-97B0-00039396E15A@bea.com>
Cc: XMLP Dist App <xml-dist-app@w3.org>
To: Jacek Kopecky <jacek.kopecky@systinet.com>

On Jan 20, 2004, at 1:15 AM, Jacek Kopecky wrote:

>> I'm not sure why it's necessary to separate it into an extension, but 
>> I
>> think we're in the ballpark.
>
> Because it makes it formally possible to produce an implementation that
> doesn't send the headers and ignores them when they arrive. A simple
> implementation. In order to allow this without the headers being an
> extension (i.e. optional) we would have to specify levels of compliance
> or we would have to use SHOULDs and MAYs etc. the right way.
> Extensibility is a simpler way to achieve the same result.

Such an implementation is not precluded if a means of carrying headers 
is specified.

To be clear; I'm not saying that we should specify how, when or if 
particular headers are serialized or interpreted; rather, I only think 
it's necessary to define a structure somewhat like this:
   <header name="...">...</header>
This will allow applications that want to use representation metadata 
to do so, and to make it available through infrastructure like HTTP 
APIs.

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.

Regards,


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Tuesday, 20 January 2004 17:23:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC