Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Wed, 15 Sep 2004 12:06:52 -0700

> -----Original Message-----
> From: Mark Baker [mailto:[email-masked]]
> Sent: Wednesday, September 15, 2004 9:48 AM
> To: David Orchard
> Cc: Atom-Syntax
> Subject: Re: Extensbility and Versioning Paces
> 
> On Wed, Sep 15, 2004 at 07:51:34AM -0700, David Orchard wrote:
> > 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?
> 
> 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.

Could this be solved by something along the lines of saying that a
mandatory extension can be scoped to feeds or entries.  Processing a
feed or an entry that contains a mandatory extension requires that the
processor understand the extension.  Processing a feed does not
necessarily require processing any or all entries.  Processing a given
entry does not necessarily require processing all entries.

> 
> 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.
> 
> > 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.
> 
> 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.
> 

XSLT 2.0 has a nifty extensibility/versioning strategy where a
stylesheet can say what the substitution alternatives for the extension
are.  It could say "catch fire and die", it could say "ignore", it could
say "do this other thing".  

It is built into the XSLT media type that this is the behaviour.  Same
as I'm proposing for atom.

> 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-)

That's totally wrong.  If the atom format says what happens with
mandatory extensions, then a processor is specifically *not* given
license to ignore.  If it ignores extensions, then it's not a compliant
atom processor. 

> 
> 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.

Huh?  I thought this was because HTTP didn't support attributes on
headers.  We're doing this on elements so we can mix in a mustUnderstand
attribute.  And if we wanted to have mandatory attributes, we'd probably
have to do the same thing as 2774.  Or do some list of "mandatory"
attributes/elements/namespaces earlier in the feed.

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

Didn't get any more input, didn't know how to proceed, and it wasn't on
the agenda so I figured I'd defer.  

Dave

---

From: Mark Baker <[email-masked]>
Date: Wed, 15 Sep 2004 16:21:14 -0400

On Wed, Sep 15, 2004 at 12:06:52PM -0700, David Orchard wrote:
> mandatory extension can be scoped to feeds or entries.

Yes.  I could have sworn I said that ...

A more general model is possible, but probably overkill.

>  Processing a

Deja vu! 8-)

> say "do this other thing".  

Neat!  I only used 1.0.

> as I'm proposing for atom.

Hmm, well, XSLT 2.0 uses a different media type than 1.0 (which was
horribly broken from a media type POV), so that seems to be a case of
introducing new media types when extensibility models are changed in a
backwards-incompatible way.

> license to ignore.  If it ignores extensions, then it's not a compliant

No.  What you seem to be missing is that there are application/atom+xml
processors already deployed (so I'm told) that don't support the
would-be mandatory-extension-supporting extensibility model.  We're not
starting from a clean slate here, Dave (though we should be, grrrr), so
it's not enough to simply write down into a spec what you want to have
happen; you need to figure out how to extend the existing architecture
to support the desired functionality, which is what I'm doing by
changing the media type.

> attributes/elements/namespaces earlier in the feed.

No no, the point was that when dealing with an existing architecture,
one must look for the proper hooks to introduce mandatory extensions.
The method is one kind of hook.  Media types are another.  Protocol
versions are yet another.  For data formats though, in the existing
Web architecture (and that of XML), it's media types or nothing.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 14:09:33 -0700 (PDT)

> to support the desired functionality, which is what

It seems you are under the impression that this
working group is somehow supposed to maintain
backwards compatibility with Atom 0.3 and the various
intermediate drafts of Atom. I'm fairly certain that
several times the chairs have said we are not to take
the pre-IETF drafts into account when defining Atom
1.0. 

We shouldn't already assume legacy in v1 of the spec.

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 15 Sep 2004 17:49:16 -0400

> We shouldn't already assume legacy in v1 of the spec.
	+1 !!!!!
	V1.0 should be the first "REAL" version. The 0.3 stuff was "proof of
concept" and a good training ground. If we allow 0.3 to hold us back, then
we might as well do what someone claimed we should do re: RSS: (i.e. "Make
all the changes needed -- as long as they result in no change"...)

		bob wyman

---

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

Hi,

On Wed, Sep 15, 2004 at 02:09:33PM -0700, Dare Obasanjo wrote:
> intermediate drafts of Atom.

I have *no* interest in backwards compatibility.  My interest is to
ensure that Atom 1.0 software will be able to avoid undesirable
collisions with Atom 0.3 software.  Sharing a common media type is
such a collision, and one that harms our ability to deploy mandatory
extensions.

> I'm fairly certain that

As it should be.

Mark.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 17:51:41 -0700 (PDT)

--- Mark Baker <[email-masked]> wrote:
> extensions

Considering that Atom 0.3 and Atom 1.0 will be utilize
different namespaces names and version numbers it
seems that there is already a lot in place preventing
collisions between Atom 0.3 clients and Atom 1.0
clients. It is a LOT more likely that these
differences will prevent Atom 0.3 clients
inadvertently consuming Atom 1.0 documents than the
MIME type differences which many discussions on this
list have shown conclusively to be much ignored on the
Web today. 

=====

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Sep 2004 00:07:32 -0400

> inadvertently consuming Atom 1.0 documents than the

Good point regarding namespaces! I hadn't considered their possible role
in this.  I agree that, practically, this addresses the mandatory
extension deployment issue I raised.

But it's still not a totally clean break from 0.3, and problems remain.
Consider that "Accept: application/atom+xml" is ambiguous about whether
it means 0.3 or 1.0.

I don't think versioning would help here at all though, since 0.3
doesn't prescribe any versioning model.

> list have shown conclusively to be much ignored on the

That's overstated.  XML media types are horribly broken, due to many
believing that */xml sufficed for all their media type needs, but
that's no fault of media types themselves.  And there are known cases of
some agents sniffing when not licensed to.  But by and large, they serve
their purpose well (which, BTW, is a purpose that cannot be entirely
replaced with other mechanisms such as namespaces).

But I don't understand what the objection is to changing the media
type?  We've changed the namespace and the version, why hold on to
another remnant of 0.3?  If backwards compatibility is really a
non-goal, let's prove it and stop using its symbols as if it were a
goal.

Mark.

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Sep 2004 14:44:57 +1000

> Consider that "Accept: application/atom+xml" is ambiguous about whether

What is meant to happen when an aggregator using that Accept header gets
back something is egregiously not application/atom+xml? For example: a html
page spat out by the cgi explaining that the database could not be connected
to.

Presumably the aggregator isn't meant to blindly trust that it gets back
what it asked for, and needs to do some basic sanity checks. Like checking
if it is actually well formed XML, and then checking that the root element
is <feed>, and that the @version attribute on <feed> is something they can
handle. Fail any of those steps and the aggregator can catch fire.

The aggregator will need safeguards to handle responses of inappropriate
formats, so why not build in a couple more checks.

e.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 16 Sep 2004 09:33:35 +0200

>Consider that "Accept: application/atom+xml" is ambiguous about whether

I would suggest you have a look at the MIME Type Registry and then come
back and tell us why we need to do anything in this regard even though
for most other formats it was decided that this is not problem that
jusifies changing the MIME type (if a problem at all).

>non-goal, let's prove it and stop using its symbols as if it were a

You have yet to demonstrate that this would be in any way relevant. And
then why this problem justifies changing the MIME Type. You did notice
that this is very difficult and expensive, no?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 16 Sep 2004 09:32:00 -0700

>page spat out by the cgi explaining that the database could not be connected

+1. No sane MIME receiver blindly accepts what it gets as correctly 
formatted. Over a decade of email experience, much less web browser 
experience, has proven that.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Sep 2004 13:13:08 -0400

> page spat out by the cgi explaining that the database could not be connected

What happens in that case is up to the agent.  But so long as the
returned content includes a media type, then all is well as the agent
will be able to determine for itself whether the server was able to
properly satisfy the request.

But that has nothing to do with my issue, which is that the meaning of
the request message is ambiguous because the media type is shared
between two incompatible specifications.

Mark.

---

From: Mark Baker <[email-masked]>
Date: Thu, 16 Sep 2004 13:39:34 -0400

> jusifies changing the MIME type (if a problem at all).

Atom 0.3 and Atom 1.0 are incompatible specifications.  They might as
well be called Joe and Bob.  That alone should be sufficient grounds to
require different media types, IMO.  Yes, it's unfortunate that 0.3 got
there first and staked claim to the canonical and easy-to-remember
"atom+xml" subtype, but such is life.

> that this is very difficult and expensive, no?

You do realize that application/atom+xml is not registered, right?  So
the same amount of work is required no matter what name we choose.

But FWIW, yes, I did notice, having been involved with two media type
registrations in the past;

 http://www.ietf.org/rfc/rfc3236.txt
 ftp://ftp.isi.edu/internet-drafts/draft-baker-soap-media-reg-06.txt

Mark.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 16 Sep 2004 20:15:45 +0200

* Mark Baker wrote:
>require different media types, IMO.

So you are saying that

  * XML 1.0 and XML 1.1 are compatible
  * CSS 1.0 and CSS 3.0 are compatible
  * SVG 1.0 and SVG 1.2 are compatible
  * HTML 2.0 and HTML 4.01 are compatible
  * HTML 2.0 and XHTML 1.0 are compatible
  * MS Word 2.0 and MS Word 2003 are compatible
  * ...

or at least more compatible than Atom 0.3 and Atom 1.0? Or do you mean
they are all wrong and MIME types are a good place to do versioning
because you say so and we should thus adopt your proposal? I am sure
I've missed something here, maybe you could explain this in more detail
to me?

>the same amount of work is required no matter what name we choose.

Apache 2.0.51 has just been released, check its mime.types configuration
file. You will notice that .atom is associated to application/atom+xml.
Using application/atom+xml for Atom 1.0 requires no work from the ASF,
using some other type for Atom 1.0 does. So, no, there is a difference.

> http://www.ietf.org/rfc/rfc3236.txt

Please tell us more about the application/xhtml+xml success story...

---

From: Tim Bray <[email-masked]>
Date: Thu, 16 Sep 2004 11:55:26 -0700

> "atom+xml" subtype, but such is life.

I think it's too late.  I did some lobbying and got the Apache and IIS 
people to agree to use "application/atom+xml" by default for the 
extension ".atom"; Apache is already shipping.  So receiving software 
is just gonna have to look at the "version=" attribute.  But it would 
have to anyhow.  No biggie. -Tim