W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2003

Re: Strawman proposal for Representation header

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 21 Nov 2003 06:54:24 +0100 (MET)
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>
Message-ID: <Pine.GSO.4.58.0311210624340.21935@gnenaghyn.vaevn.se>

On Wed, 19 Nov 2003, Mark Nottingham wrote:

> I agree that that's one way to view resources that vary according to
> request headers, but it isn't the only one. Strictly speaking, a
> resource that varies over request headers can be thought of in the same
> way as one that varies over time; that is, as a resource with a number
> of representations that vary over some axis.

Sure, the number of axis is not an issue, as the Vary: header can have
multiple of them listed, and if you store revisions over time, you would
be able to do that (see the "latest news" vs "news of this parcitular day"
issue)

> > Well, if we have to embed a representation in the message, then the
> > originator of the SOAP message has to access the resource with its own
> > preferences
>
> Is there an assumption here about the MEP? E.g., how would this happen
> in a one-way MEP?

The MEP was one way, but to embed a http URI content in your message, you
require a typical http interaction, but it is not related to the SOAP MEP

> I think that describing this format as a fully offline portable cache
> (both more fully-featured and more respectful of HTTP than MHTML) is
> INTENSELY interesting, and would find it quite easy to be happily
> diverted by it for quite a while (as you probably know, Yves!) but I
> wonder if our fellow WG members share these feelings... there could be
> a considerable amount of work, because I don't think that this part of
> HTTP was ever very fully specified, and conneg has its own failings as
> well.
I was just identifying a real issue about what we want to do so that the
WG can decide what to do and clearly signal the capabilities and
limitations of what we will have at the end. In our case, I claim that we
don't need a generic offline cache definition, as we will only have to
deal with one cached URI at a time.
But the real gist of the issue is to identify what we want to do at the
processing level, a URI resolver or just a fallback in case the real URI
can't be reached.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Friday, 21 November 2003 00:54:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:15 GMT