Subject: RE: Published extensibility Paces

From: "David Orchard" <[email-masked]>
Date: Thu, 11 Nov 2004 13:54:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> > Also, does the removal of version imply a resolution to Atom
Component
> > Identification that is the use of atom namespace name changes + mU
to
> > indicate incompatible versions, as I had proposed?
> 
> I totally didn't understand that question, and I bet there are others
> similarly puzzled.  Want to try again? -Tim

Cough.  Sure.  

My original pace gives any future of Atom 2 choices for indicating an
incompatible change, but revised with your proposal to:
1. Revise any of the Feed or Entry QNames, ie <atomnext:feed>.  
2. Use a mustUnderstand, ie <atom:feed><mu><ns>atomnext</ns></mu>.

I don't like staying just at #2, which is what I think you are implying,
because we shouldn't constrain the future version of Atom in it's
choices for using namespace names to indicate compatible or incompatible
versions.

I'd written up some rules in my pace for the choices that future
extensions or versions, by either atom or not atom authors, could use
namespaces and that included #1 and #2.

Cheers,
Dave

---

From: "David Orchard" <[email-masked]>
Date: Thu, 11 Nov 2004 17:25:06 -0800

Then I don't have to respond to your rudeness.  Excellent.

> From: Graham [mailto:[email-masked]]
> Sent: Thursday, November 11, 2004 3:33 PM
> To: Tim Bray
> Cc: David Orchard; Atom WG; Walter Underwood
> Subject: Re: Published extensibility Paces
> 
> On 11 Nov 2004, at 11:13 pm, Tim Bray wrote:
> 
> > On Nov 11, 2004, at 2:53 PM, Graham wrote:
> >
> >> I ask, once again, what the bloody hell is a mandatory extension?
> >
> > One in a namespace which is listed in the atom:must-understand
> > element.  Since we don't currently have must-understand in the
draft,
> > there is no such thing. -Tim
> 
> Dave: Mandatory extensions beget atom:must-understand
> Tim: atom:must-understand begets mandatory extensions
> 
> I have decided that Shrook understands all possible extensions but is
> consciously choosing not to display whatever they might contain. Thus
I
> don't have to implement any of this nonsense.
> 
> Graham

---

From: "David Orchard" <[email-masked]>
Date: Fri, 12 Nov 2004 10:36:33 -0800

That's correct.  

There are often concerns about the scope of mustUnderstand and failures.
One of the proposals in the past was that a mustUnderstand on an entry
would not cause a feed aggregator to fail.  The problem is what is a
feed aggregator?  

XML defines 2 conformance levels, well-formed and valid.  Atom could
easily do something similar, say a "feed" and an "entry" conformance
level for mU.  I had asked for some explanation of various profiles
previously but didn't get any response.  But even that definition can be
complex and people are leery about defining any kind of
processor/conformance/profile levels.

Another approach is to split the mU into 2 levels: feed mUs and entry
mUs.  

BTW, this is roughly why SOAP introduce the "role" attribute.  But I
haven't been able to clearly think through how soap roles could be used
in combination with the various models of processors to handle mU.

Cheers,
Dave

> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Walter Underwood
> Sent: Friday, November 12, 2004 9:23 AM
> To: Atom WG
> --On Thursday, November 11, 2004 11:32:32 PM +0000 Graham
<[email-masked]>
> wrote:
> > consciously choosing not to display whatever they might contain.
Thus I
> Extensions might not be separate displayable things. Maybe it is info
> for a micropayment scheme.
> 
> In general Shrook would have to implement it, but the implementation
> is very simple.
> 
> If the doc has MustUnderstand extensions, and the software doesn't
> implement all of them, then the software must reject the entire
document.
> Not just the extensions, the whole thing. Compare it against the local
> list,
> then toss or pass the whole feed.
> 
> I'm not arguing for or against MustUnderstand, just trying to keep
> this accurate.
> 
> wunder
> --
> Walter Underwood
> Principal Architect
> Verity Ultraseek