Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Wed, 15 Sep 2004 07:51:34 -0700

Resending.

I've heard the issue about scoping of mustUnderstand before.  I didn't
really get a good read on the scenario for what a client wanted to
happen if it wanted to mark an element as required.  Are there 2 classes
of feed processors?  The "parse the feed but not the entries" and the
"parse the entries" and the mU would be targeted at the 2nd but not the
first?

For mandatory extensions, I disagree with changing the media type.  I
don't think that the media type is required to change for every
incompatible version change.  I don't think that html, xml, xslt have
done that.

[1] http://www.imc.org/atom-syntax/mail-archive/msg07427.html

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Mark Baker
> Sent: Tuesday, September 14, 2004 10:07 PM
> To: Atom-Syntax
> Subject: Re: Extensbility and Versioning Paces
> 
> 
> I'm -1 on PaceAltExtensibilityAndVersioning, and -0 on
> PaceExtensibilityAndVersioning.  I do believe that the latter is a far
> better starting point (i.e. minus explicit versioning), but I think
the
> use of mandatory extensions is too simplistic as it doesn't consider
> the scope of those extensions.
> 
> Consider that the pace currently says;
> 
> 'An atom compliant processor MUST process all elements marked with
> mustUnderstand="true" or process none at all.'
> 
> which says to me that if there's just one entry in a feed which has a
> mandatory extension that isn't understood, that the entire feed is
then
> not processable.  I don't believe that this behaviour is what is
> desired.  So I'd propose that mandatory extensions be scoped such that
> having them on a feed means the whole feed will be rejected when not
> understood, but having them on an entry just means that the entry will
> be.  This brings up the issue of how scopes can be extended, such as
if
> somebody wanted to extend Atom with a sibling to entry, but I think it
> would be overkill to go there yet.
> 
> I also believe that any proposal for an extensibility mechanism that
> introduces mandatory extensions needs to change the name of the media
> type, at least when there's deployed code which supports the old media
> type.  This is because that old code has no knowledge of the addition
> of mandatory extensions and therefore will not behave properly when
> confronted with them.
> 
> I'm working on PaceExtensibilityAndVersioning2, but it's getting late
> and I won't finish it tonight.  I should have some time tomorrow
night.
> 
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Mark Baker <[email-masked]>
Date: Wed, 15 Sep 2004 12:47:39 -0400

> "parse the entries" and the mU would be targeted at the 2nd but not the

No, not really.  There's an infinite number of kinds of Atom processors,
and I'm just interested in specifying what's common to them all.  For
example, one might choose to only process ever other entry, in which
case it shouldn't be expected to halt and catch fire if an entry it
doesn't process has a mandatory extension that it doesn't recognize.
But, it should barf if there's an unrecognized mandatory extension on
the feed.  Another type of processor might ignore entries all together.
Conversely, all processors must process the feed, and therefore be
prepared to handle mUs on feed extensions.

As for what a publisher expects when using a mandatory extension, I
would expect that it was that the entry/feed not be processed.  What
actually happens, i.e. what it means for it not to be processed, is up
to the agent itself.  I don't believe we should be specifying that.

> incompatible version change.  I don't think that html, xml, xslt have

I don't think it needs to change for every incompatible version change,
only the ones which require strict processing behaviour, like mandatory
extensions ... which none of those standards you list supports.

If we don't change the media type, then we are giving existing Atom
implementations license to *ignore* those extensions, which kinda
defeats the whole purpose of having them; they are *mandatory*, after
all!! 8-O 8-)

FWIW, as an instance of prior art, this is why RFC 2774, when adding
mandatory extensions to HTTP, had to define the "M-" prefix for methods.

Sorry, I missed the earlier discussion about scoping; any particular
reason why that didn't make it into your pace?

Mark.