Subject: RE: Version vs. Namespace

From: "David Orchard" <[email-masked]>
Date: Mon, 12 Jul 2004 14:05:07 -0700

Excellent.  I've been writing up some of the usual mU/mustIgnore stuff.  We do have experience in that.  

I strongly disagree with the use of a version attribute for claiming major and minor versions.  I believe that QNames are the right way to go for identifying elements, not qnames+versions.  

Norm and I have written up material on why coarse grained version #s are bad [1] and even used RSS as an example.  We have implementation experience on using version #s, and it isn't that great.

Cheers,
Dave

[1] http://www.w3.org/2001/tag/doc/versioning#problems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tim Bray
> Sent: Monday, July 12, 2004 10:24 AM
> To: Atom Syntax
> Subject: Re: Version vs. Namespace
> 
> 
> 
> On Jul 12, 2004, at 9:17 AM, David Orchard wrote:
> 
> > While Mark's proposal of a profile might appear to be 
> complicated, it 
> > ought to get a bit more air time and explanation than the very next 
> > message saying "no", especially with discussion of concrete use 
> > cases/scenarios.
> 
> OK.  I claim that a single fixed namespace plus a single version 
> attribute on the root element, plus an extensibility framework 
> involving the usual mustUnderstand/mustIgnore primitives, 
> will provide 
> a nice efficient framework for the long term.  I further claim that 
> there is now enough experience with this kind of versioning 
> architecture that we understand the implementation issues.  I further 
> express doubt that any further steps down the road to more complexity 
> will have positive ROI.
> 
> So...... those who want a more complex and abstract versioning set-up 
> should start, I think, from use-cases, so that we get a nice clean 
> clear sense of exactly what the complexity buys us.  -Tim
> 
>

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Jul 2004 15:41:07 -0600

+1 on the use of namespace to indicate version as opposed to a version 
attribute.

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

"David Orchard" <[email-masked]> 
Sent by: [email-masked]
07/12/2004 02:05 PM

To
"Tim Bray" <[email-masked]>, "Atom Syntax" <[email-masked]>
cc

Subject
RE: Version vs. Namespace

Excellent.  I've been writing up some of the usual mU/mustIgnore stuff. We 
do have experience in that. 

I strongly disagree with the use of a version attribute for claiming major 
and minor versions.  I believe that QNames are the right way to go for 
identifying elements, not qnames+versions. 

Norm and I have written up material on why coarse grained version #s are 
bad [1] and even used RSS as an example.  We have implementation 
experience on using version #s, and it isn't that great.

Cheers,
Dave

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 14:49:17 -0700

On Jul 12, 2004, at 2:05 PM, David Orchard wrote:

> Norm and I have written up material on why coarse grained version #s 
> are bad [1] and even used RSS as an example.  We have implementation 

I just read that, and I certainly agree with its line of argument, but 
I'm not convinced about the version number.  The example of RSS doesn't 
work, RSS's "version numbers" (0.9*, 1.0, 2.0*) aren't anything like 
version numbers.  I propose the following policy:

1. Atom documents have a version number which identifies a version of 
the governing specification, and there is a clear ordering relationship 
among released versions.
2. Atom software implementations declare conformance to some version 
number
3. When Atom software encounters Atom-namespace markup from its own or 
an earlier version, and doesn't recognize that markup, i.e. it's not in 
the specification for its version, that's an error.
4. When Atom software encounters Atom-namespace markup from a later 
version than its own, by default it applies a MustIgnore policy unless 
the markup carries the attribute policy="mustUnderstand"
5. When Atom software encounters markup from namespaces other than 
Atom, it MAY ignore that markup (doesn't prevent people from agreeing 
on extensions).

Note:
- you could make MustUnderstand instead of MustIgnore the default
- you could imagine another way to signal the policy, i.e. a containing 
element or something
- you could put new stuff in a different namespace

  -Tim

---

From: Martin Duerst <[email-masked]>
Date: Tue, 13 Jul 2004 07:37:27 +0900

At 14:49 04/07/12 -0700, Tim Bray wrote:

>I just read that, and I certainly agree with its line of argument, but I'm 
>not convinced about the version number.  The example of RSS doesn't work, 
>RSS's "version numbers" (0.9*, 1.0, 2.0*) aren't anything like version 
>numbers.  I propose the following policy:
>
>1. Atom documents have a version number which identifies a version of the 
>governing specification, and there is a clear ordering relationship among 
>released versions.
>2. Atom software implementations declare conformance to some version number
>3. When Atom software encounters Atom-namespace markup from its own or an 
>earlier version, and doesn't recognize that markup, i.e. it's not in the 
>specification for its version, that's an error.
>version than its own, by default it applies a MustIgnore policy unless the 
>markup carries the attribute policy="mustUnderstand"

Big question:
How does an Atom implementation that is conformant e.g. to version
2.48 decide whether unknown Atom-namespace markup is 'from its own or
an earlier version but not in the specification' or 'from a later
version than its own'? Even more to the point, does it make sense to
speak about markup 'from its own or an earlier version but not in the
specification'? Sounds like a contradiction to me, unless I missed
something.

Regards,    Martin.

>5. When Atom software encounters markup from namespaces other than Atom, 
>it MAY ignore that markup (doesn't prevent people from agreeing on extensions).
>
>Note:

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jul 2004 15:52:31 -0700 (PDT)

--- James M Snell <[email-masked]> wrote:
> [1]
> http://www.w3.org/2001/tag/doc/versioning#problems

I read the information in the TAG document and didn't
see a compelling argument against using version
numbers besides pointing to the RSS debacle whose
current state has little to do with the existence or
lack version attributes on root elements. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 16:05:04 -0700

On Jul 12, 2004, at 3:37 PM, Martin Duerst wrote:

>> 3. When Atom software encounters Atom-namespace markup from its own 
>> or an earlier version, and doesn't recognize that markup, i.e. it's 
>> not in the specification for its version, that's an error.
>
> Big question:
> version than its own'?

Because instances have version numbers.  I.e. it sees <atom:feed 
version="2.0">
as opposed to <atom:feed version="3.0">

> Even more to the point, does it make sense to

I mean, if the 2.0 code sees

<atom:feed version="2.0"><atom:frob />

and "frob" isn't in the specification, then that's an error. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jul 2004 17:15:36 -0700 (PDT)

> as opposed to <atom:feed version="3.0">

So Atom will not be backwards compatible? Every time
Atom is revved and some early adopter blog vendor
decides to support it, my users will have to wait for
me to ship another version of RSS Bandit? 

=====

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 17:23:57 -0700

> me to ship another version of RSS Bandit?

Huh?  I thought I'd covered that in 
http://imc.org/atom-syntax/mail-archive/msg06762.html -  I proposed a 
default rule of MustIgnore if you see an element you don't recognize in 
a feed whose version is higher than the version the software knows.  
Shouldn't that cover it?  I mean, an <atom:title> is still an 
<atom:title> five years from now unless we foolishly change the 
namespace, the assumption should be exactly that you can process the 
markup you know from future versions unless it's explicitly marked 
MustUnderstand.  -Tim

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 20:54:38 -0400

On 12 Jul 2004, at 8:23 pm, Tim Bray wrote:

> default rule of MustIgnore if you see an element you don't recognize 
> in a feed whose version is higher than the version the software knows. 
> MustUnderstand.

If a version n atom:title has to be 100% compatible with a version m 
atom:title, what's the version attribute for? According to that last 
message, the only difference is enforcement of mustUnderstand in later 
versions - but shouldn't mustUnderstand be enforced in all versions? ie 
If the software doesn't understand any mustUnderstand element, even one 
from a version it is familiar with?

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jul 2004 18:15:24 -0700 (PDT)

> Huh?  I thought I'd covered that in 
http://imc.org/atom-syntax/mail-archive/msg06762.html

Oops I missed that message. There's a lot of traffic
on the list. :) 

Those rules seem fine with me except they don't
account for backwards incompatible changes. This is a
key part of any versioning story. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 19:03:57 -0700

> key part of any versioning story.

For incompatible changes, I really only see two options:

1. Provide a way to signal MustUnderstand so that back-rev software can 
fail gracefully.
2. Use a different namespace.

Are there any other options? -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jul 2004 19:12:52 -0700 (PDT)

> Are there any other options? -Tim

None that I know of. The MustUnderstand mechanism can
vary (e.g. semantics of major version number in
version attribute, mustunderstand attribute, etc) but
that's about it. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 12 Jul 2004 22:30:33 -0400

> the governing specification, and there is a clear ordering relationship

While I like this proposal in general, I believe the 
'clear ordering relationship among released versions'
is where this might break down. Consider for example
the XHMTL 1.1 + MathML 2.0 + SVG 1.1 Profile [1].

This isn't XHTML 2.0, nor is it XHTML 1.2, it is
a leaf on what could become a very full tree of
profiles. This doesn't fall into the category of 
monotonically increasing version numbers.

XHTML is also a poor example of monotonically
increasing version numbers since XHTML 2.0 
has no compatibility with XHTML 1.1.

If we have a clear extension mechanism for 
Atom, given the level of activity we are seeing on the list
these days, after the 1.0 release I could 
well imagine several groups
breaking off to pursure 'modules' for Atom, say for
syndicating large multimedia objects, or calendar
data, etc. I believe it would be helpful to have a 
profiling mechanism that allows those modules
to be blended back into an Atom 1.0 feed and
not require a new Atom format spec with a bumped up
version number. It would also be useful
to indicate what version of Atom a module
could be used with.

In short, I believe we need to define
an extension mechanism that allows
new 'modules' to be created, a profiling 
mechanism that indicates which 'modules'
are being combined, and an indication of 
which version of the core Atom syntax is being
used. 

Given the experience of XHTML and RSS
I don't believe a version number would be any 
clearer than a version 'string' or a change in
the namespace URI.

[1] http://www.w3.org/TR/2002/WD-XHTMLplusMathMLplusSVG-20020809/

    Thanks,
    -joe

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 19:33:42 -0700

On Jul 12, 2004, at 7:03 PM, Tim Bray wrote:

> 1. Provide a way to signal MustUnderstand so that back-rev software 
> can fail gracefully.

Can you spell out option #1 (or give a reference into this sea of bits 
we call the mailing list)? On the face of it, I don't see how a mU bit 
is adequate on its own (it makes a lot of sense in conjunction with a 
different namespace).

Thanks,

--
Mark Nottingham     http://www.mnot.net/

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 12:45:56 +1000

> markup you know from future versions unless it's explicitly marked

what happens when there is another rev? how far back does MustUnderstand
apply? more importantly, how far forward will MustUnderstand flags be
carried forward ... will we see a future version where nearly everything is
encrusted because at some various point it needed MustUnderstand? We can't
ever take it off an element, because what happens when a 2.0 code encounters
a 4.0 document (where the 3.0 revved it with MustUnderstand)?

could we not have, effectively, two version numbers -- the version this feed
is in, and the minimum version it is backwardly compatible with? or does
that not provide enough granularity?

e.

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 20:00:07 -0700

> monotonically increasing version numbers.

"Doctor, it hurts when I do this."  "Don't do that."

I think that having a clear, simple versioning policy is worth a lot; 
and nobody would want to emulate the process by which the various 
flavors of HTML were produced.  If we write Atom 1.0 with a clear 
guideline that the versioning policy depends on future versions being 
well-ordered, it will be clear to anyone who produces a later version 
that isn't that they will be breaking Atom versioning.  Whereas nobody 
can prevent future stupidity, it would seem a fairly unlikely scenario.

> to indicate what version of Atom a module

I would argue that they should be done in different namespaces.  The 
goal you set, while worthy, is going to be very difficult to achieve.  
As a veteran of some years in the publishing-technology industries, I 
don't recall ever seeing a versioning/extensibility framework that was 
as general as what you describe and still comprehensible by mere 
mortals.

I think that linear version numbers plus MustIgnore hits a huge 80/20 
point. -Tim

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 20:44:33 -0700

> a 4.0 document (where the 3.0 revved it with MustUnderstand)?

Please read the proposal again, it's much simpler than what you're 
describing.  There are only two possible relationships between software 
and Atom instances: (1) I should understand this, its version number is 
<= than mine, or (2) it postdates me, its version # is > mine.  In case 
(1), atom markup I don't know is an error.  In case (2) Atom markup I 
don't know is to be ignored, unless it's labeled MustUnderstand *right 
there in the instance*, in which case I report an error.  -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 21:26:43 -0700

At 8:00 PM -0700 7/12/04, Tim Bray wrote:
>If we write Atom 1.0 with a clear guideline that the versioning 
>policy depends on future versions being well-ordered, it will be 
>clear to anyone who produces a later version that isn't that they 
>will be breaking Atom versioning.  Whereas nobody can prevent future 
>stupidity, it would seem a fairly unlikely scenario.

Lots of experience in the IETF reflects this reality. The better the 
version policy is described in the 1.0, the less likely it is that 
someone will do it wrong. The converse has even more examples, 
unfortunately.

>I think that linear version numbers plus MustIgnore hits a huge 
>80/20 point. -Tim

I would like to see this specifically shown against Mark's scenario 
list from earlier today.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 08:45:46 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| On Jul 12, 2004, at 7:03 PM, Tim Bray wrote:
|
|>
|> On Jul 12, 2004, at 6:15 PM, Dare Obasanjo wrote:
|>
|>> Those rules seem fine with me except they don't
|>> account for backwards incompatible changes. This is a
|>> key part of any versioning story.
|>
|> For incompatible changes, I really only see two options:
|>
|> 1. Provide a way to signal MustUnderstand so that back-rev software
|> can fail gracefully.
|> 2. Use a different namespace.
|
| Can you spell out option #1 (or give a reference into this sea of bits
| we call the mailing list)? On the face of it, I don't see how a mU bit
| is adequate on its own (it makes a lot of sense in conjunction with a
| different namespace).

In a nutshell, if an application sees:

  <atom:undefinedName atom:mustUnderstand="true">xxx</atom:undefinedName>

then it must halt and catch fire. If it sees:

  <atom:undefinedName atom:mustUnderstand="false">xxx</atom:undefinedName>

it just ignores the element. I feel pretty strongly that the default
value of atom:mustUnderstand should be "false", but it's an open
question.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Endurance is frequently a form of
http://nwalsh.com/            | indecision.--Elizabeth Bibesco

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 13 Jul 2004 12:35:39 -0700 (PDT)

> is adequate on its own (it makes a lot of sense in

It depends on the kind of backwards incompatible
change. Adding required elements or new attributes to
an element can be signalled with mustUnderstand.
Changing the semantics of an element on the other hand
can likely not be signalled just with mustUnderstand.
However there seems to be consensus that this is a bad
thing to do. 

=====