Re: entity header

Oh, I totally forgot about the content-type thing... MarkN and Yves
reminded me that I also expect we'd use something like the 
xmime:content-type attribute on the body (Data) element instead of
making it a metadata property. With this, I think the metadata element
should go from the core proposal because it's no longer needed.
Basically, I suggest we go back to 

<foo:Representation resource="uri">
  <foo:Data xmime:content-type="...">...</foo:Data>
</foo:Representation>

Which only contains the Data element above what PASWA originally
suggested; and this is intended to enable element-based extensibility of
the Representation header.

Jacek

On Wed, 2004-01-14 at 15:53, Jacek Kopecky wrote:
> 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 11:08:12 UTC