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

Re: entity header

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 14 Jan 2004 15:17:59 +0100 (MET)
To: Mark Nottingham <mark.nottingham@bea.com>
Cc: xml-dist-app@w3.org
Message-ID: <Pine.GSO.4.58.0401141514550.14422@gnenaghyn.vaevn.se>

On Wed, 7 Jan 2004, Mark Nottingham wrote:

> Counter-proposal:
>
> <x:Entity>
>     <x:metadata>
>        <x:header name="bar">baz</x:header>
>        <x:header name="boo">1</x:header>
>        ...
>     </x:metadata>
>     <x:content>
>        ...
>     </x:content>
> </x:Entity>
>
> with extensibility in attributes as well as children of entity and
> metadata. It is ONLY a means of representing a MIME(-like) entity;
> application semantic is not implied.

So you mean you want only the headers of the reply and no interpretation
of them?
From what I understood before, having a normalized way to say "this is of
type image/jpeg" instead of knowing all the header form of all protocol is
something desirable (hence the meta/rawmeta proposal).
Also in some case the headers of the request might be used.
I'm ok to leave of the intent that seems to be more confusing than
anything else.


>
>
>
> On Dec 9, 2003, at 1:52 PM, Yves Lafon wrote:
>
> >
> > Here is something that enable multiple behaviour.
> > The rationale for having such entity header is related to UC2,
> > embedding a
> > representation of a resource (usually a web resource) to an endpoint
> > that
> > might or not be able to deference it. Also the capabilities are
> > unknown,
> > so the "generic HTTP cache behaviour" has to be possible (but not
> > mandatory)
> > Here is my proposal...
> >
> > <foo:Entity>
> >   <context>
> >     <request>
> >       <header name="Accept">application/soap+xml, image/svg+xml,
> > image/jpeg</head>
> >     </request>
> >   </context>
> >   <rawmeta>
> >     <header name="Vary">Accept</header>
> >     <header name="Content-Type">image/svg+xml</header>
> >      ...
> >   </rawmeta>
> >   <meta>
> >     <property name="Content-Type">image/svg+xml</property>
> >   </meta>
> >   <processing>
> >      http://www.w3.org/2003/12/fullhttpcache
> >   </processing>
> >   <body>...</body>
> > </foo:Entity>
> >
> >
> > Where rawmeta is the metadata received, without requiring understanding
> > it, meta being the one known (I suggest to put only common MIME
> > headers,
> > like Content-Type).
> > And a processing EII pointing to a URI defining the default behaviour.
> > If
> > unknown we can propose the safe bahaviour of "get from the net and if
> > it
> > fail, use the copy". But we will need to explicit the different
> > behaviours for each URI used.
> >
> > Do we need to put the request URI there as well? (in context).
> >
> > Note that I made a special case for a negotiated resource, where many
> > things are needed. depending on the resource and the processing model
> > used, most header can be absent, leading to a far mor simple version of
> > it.
> >
> > Comments?
> >
> > --
> > Yves Lafon - W3C
> > "Baroula que barouleras, au tiéu toujou t'entourneras."
>
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Wednesday, 14 January 2004 09:18:53 UTC

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