Answering some of your questions brought up some
more questions on how this would work:
1. Does mustUnderstand apply no matter what I am doing to the feed?
For example, combining multiple feeds into a single synthesized feed?
How about validating a feed?
2. How does this relate to SOAP's mustUnderstand role in the
protocol part. From my understanding of SOAP the
mustUnderstand attribute indicates a header that must be
processed. From the 1.2 SOAP spec:
"Mandatory SOAP header blocks are presumed to somehow
modify the semantics of other SOAP header blocks or SOAP
body elements."
In the case of the protocol that 'body element' is an Atom feed
or entry. What if I were truly evil and spec'd a mandatory SOAP
header whose purpose was to force the atom:must-understand
element to be ignored?
And this is just the evil I could come up with after
a few minutes of thinking about it. Give me some time and I could
probably do much worse :)
-joe
On Wed, 10 Nov 2004 15:04:47 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> I had a talk about Atom and extensibility with Dave Orchard this
> morning, and he convinced me that there is benefit in a must-understand
> facility, but then educated me as to how complex it can be to
> implement.
>
> Based on that discussion, I have just published
> PaceMustUnderstandElement and PaceExtendingAtom. Note that the WG
> could reject PaceMustUnderstandElement and I think that
> PaceExtendingAtom would still work.
>
> For convenience:
> http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
> http://www.intertwingly.net/wiki/pie/PaceExtendingAtom
>
> -Tim
>
>
--
Joe Gregorio http://bitworking.org
