Re: entity header

Yves, 

if I (finally) understand it correctly, the minimal syntax would be

<foo:Entity>
  <foo:body>...</foo:body>
</foo:Entity>

And the second minimal (with mime-type indication) would be 

<foo:Entity>
  <foo:meta>
    <foo:property name="Content-Type">image/svg+xml</foo:property>
  </foo:meta>
  <foo:body>...</foo:body>
</foo:Entity>

Both examples are missing (as is the full proposal of yours) the URI of
the resource whose representation this thing is. I seem to have failed
to notice this before, but I expect this is only a simple omission.
Let's assume the Entity element has an attribute resource="URI".

I have nothing much against the form above. My main issue is that I
don't think we need to do anything more above this. Let's say that all
we specify is the above and that it's extensible (as a good XML language
should be). If somebody needs to provide raw protocol response and/or
request headers, they can introduce an extensibility element, say
<bar:context> or <baz:rawmeta> etc. The namespaces bound to bar: or baz:
could clarify that this information is usable for full caches. The
processing element is unnecessary, IMHO.

In fact, we could produce a separate deliverable (a different section,
an appendix or a separate document) that would specify such headers.
What I'm concerned about is the minimal implementation - if the
namespace contains all the context and rawmeta stuff, all
implementations will be expected to implement it. 

Alternately we could specify conformance levels (simple Entity, Entity
with context and raw metadata) but I believe doing so using XML
namespaces is cleaner and more uderstandable.

Now for my minor issues: I suggest the header be renamed to
"Representation", that the "resource" attribute be added, that all
element names have an upper-case initial letter; and that "Body" be
renamed to "Data". This would result in the following:

<foo:Representation resource="uri">
  <foo:Meta>?
    <foo:Property name="Content-Type">image/svg+xml</foo:Property>*
  </foo:Meta>
  <foo:Data>...</foo:Data>
</foo:Representation>

Further changes might involve URI-izing or QName-izing the property
names (if it's an extensible set, which I presume it is) or other
tweaking of the metadata syntax.

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/





On Wed, 2003-12-17 at 13:03, Yves Lafon wrote:
> On Wed, 10 Dec 2003, Jacek Kopecky wrote:
> 
> > Yves, all,
> >
> > this proposal is extremely complex (considering what I think we want to
> > achieve). I'd suggest we split it into different syntaxes according to
> > the processing URIs.
> 
> Well, the goal was to allow very straightforward use of the attached
> representation as well as more subtle processing (like aloowing the
> receiving end to act as a HTTP compliant cache). Of course, processing is
> not mandatory (I should have changed <processing> to <intent> or something
> like that to clearly indicate that).
> 
> 
> > Concretely, I'd define the foo: namespace as something like
> > http://www.w3.org/2003/12/fullhttpcache and I'd remove the processing
> > EII from the children of foo:Entity.
> 
> Well, in that case an implementation that know only the
> http://www.w3.org/2003/12/usethis will fail to recognize the entity
> header.
> With <intent>, an implementation that know only the "usethis" way of
> processing this will just ignore the extra EII it doesn't need to know.
> It is just a way to characterise what is attached, not a mandatory
> "process it this way or fail" thing.
> 
> > To cover the simple cases (see below), I'd define something as simple as
> >
> > <ns:Representation uri="..." xmime:mediaType="..."?>
> >      ... base64 data ...
> > </ns:Representation>
> >
> > (remarkably similar to what PASWA proposed, I believe), with the
> > semantics of "if the receiver is dereferencing the given URI and it
> > thinks the presented representation will suit it, it may use it."
> >
> > The thing is, applications that need to receive resource representations
> > along with the messages (because they are constrained in some ways) are
> > usually hard-coded to work with the received representation no matter
> > what, and the senders know that (are hard-coded, too) and send the right
> > stuff.
> >
> > I don't see myself ever using the full foo:Entity (as proposed) in any
> > kind of real SOAP application. For me, the immensely simpler
> > ns:Representation would do. Therefore I suggest we consider both
> > approaches in parallel, and I vote that we do not work further on the
> > general foo:Entity stuff and that we continue with the limited
> > ns:Representation. 8-)
> 
> As said earlier, a valid implementation can just ignore things not
> intended for its level of processing, and can be hardwired to do just the
> simple stuff if that's the only thing you need (for now).
> 
> Imagine that you (well, not you ;) ) want to use SOAP+MTOM to carry
> updates between distributed HTTP caches, the need of having the
> fullhttpcache level might be good to ensure the content if updated the
> right way.
> 
> 
> 
> > > 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?
> >

Received on Wednesday, 14 January 2004 09:53:56 UTC