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

Re: Representation header final proposal

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 21 Jan 2004 14:03:27 +0100 (MET)
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: Jacek Kopecky <jacek.kopecky@systinet.com>, XMLP Dist App <xml-dist-app@w3.org>
Message-ID: <Pine.GSO.4.58.0401211357030.27812@gnenaghyn.vaevn.se>

On Tue, 20 Jan 2004, Mark Nottingham wrote:

> > 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.

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).

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 21 January 2004 08:07:28 UTC

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