/ Mark Nottingham <mnot@xxxxxxxx> was heard to say:
My two cents. I'm aiming here for short, simple, easy to understand
answers.
But in order to be *able* to answer these questions, you have to have
a versioning policy *in place* in V1.0. So here's my suggestion for a
versioning policy for V1.0. My answers below are based on this policy:
- No element in a namespace other than the Atom namespace is allowed
to change the semantics of any element in the Atom namespace.
(You can't introduce an extension element that means ignore the
atom:title and use the atom:summary for the title instead.)
- Any element may have an atom:mustUnderstand attribute. If
atom:mustUnderstand=true and the element is unrecognized,
that's an error. Halt and catch fire.
- If you're reading an Atom document with a version identifier that
you recognize:
- Unrecognized elements in the Atom namespace are an error.
Recovery behavior is to ignore them.
- Unrecognized elements in any other namespace are ignored.
- If you are reading an Atom document with a version identifier that
you don't recognize:
- Unrecognized elements in the Atom namespace or any other
namespace are ignored.
This policy is not sufficient to get the sort of distributed
backwards/forwards compatible processing that DaveO and I describe in
the versioning finding, but I think it's right conceptually. (What I
haven't specified are some ugly details that you need to work out in
order to get around XSD's problems with ambiguity.)
| 1) And it was good... except for that nasty atom:title element; after
| wide deployment experience, it's agreed we need a new version of it.
| So, a new version of Atom is introduced. The new one isn't
| backwards-compatible with the old one.
A backwards-incompatible change tips over the apple cart. This version
of Atom goes in a new namespace; it's a different document type.
This is really painful, so let's plan not to do this, ok? :-)
| 2) Then, we decide we want to add a new metadata element, let's call
| it "fog." So, a new version of Atom is introduced.
One answer is to put this element in a different namespace. Then
there's no problem.
Another answer is to put this element in the Atom namespace and bump
the version identifier. That's no problem either as long as fog doesn't
change the semantics of any other Atom element.
| 3) After a while, someone comes up with a souped-up version of
| atom:title that is backwards-compatible, just *better*. It gets really
| popular, and yet another version of Atom is born.
Bump the version identifier. No problem.
| 4) At the same time, a group of rogue Open Source Software programmers
| descends upon this idyllic scene and introduces its own extensions. Up
| until now, all of our extensions have been approved and incorporated
| by the WG, but these are destined to remain separate.
They get left in a separate namespace. Applications that recognize them,
do, and applications that don't, don't.
If they get put in the Atom namespace then they fall into either
cateogry 1 or category 2.
| 5) Finally, in 2010, we realise that the Atom feed and entry
| containers aren't really doing the job, and we need to change their
| model. Yet Another Version of Atom (YAVA) comes into being.
That's just 1 or 2 again, depending on whether or not the change is
backwards compatible.
Be seeing you,
norm
--
Norman Walsh <ndw@xxxxxxxxxx> | Most human beings have an almost
http://nwalsh.com/ | infinite capacity for taking things for
| granted.--Aldous Huxley
Attachment:
pgp00119.pgp
Description: PGP signature