Choosing A Webhost:
A web hosting service is a type of Internet hosting service that allows individuals and organizations to provide their own website accessible via the World Wide Web. Web hosts are companies that provide space on a server they own for use by their clients as well as providing Internet connectivity, typically in a data center. Web hosts can also provide data center space and connectivity to the Internet for servers they do not own to be located in their data center, called colocation. more...
|
Re: entity header: msg#00002
text.xml.distributed
|
Subject: |
Re: entity header |
I tend to think we're just defining an XML structure whose semantic is
"I can be transformed into a MIME entity, if you want to," and we want
to when we do MIFFY<->plain XML conversions.
Any other application-specific or infrastructure-specific semantic can
be added by extending that structure, if necessary.
On Dec 17, 2003, at 4:03 AM, 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?
--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
| |
