[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Usage Scenarios for Versioning and Extensibility


Thanks, Norm - comments / questions inline.

On Jul 13, 2004, at 5:40 AM, Norman Walsh wrote: 
- 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.)

Agreed.

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

Rather than "any element", can we say "any child element of atom:feed or atom:entry" (adjusted to account for what we do with feedinfo, etc.)?

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

Is there any difference between these two sub-cases, except in who has control of the namespace?

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


Yes, as long as they don't have a mustUnderstand=true flag.

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

Yes. If it's not backwards-compatible, it gets a new namespace URI and/or localname.

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

Agreed, except I don't see the need to bump the version identifier, UNLESS we say that "fog" is now required, etc. for the feed itself to be valid. See end of message for more discussion.

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

If it's backwards-compatible, what purpose is served by changing the version identifier?

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

Yes.

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

Agreed.

One thing that might be helpful to clarify is what the version identifier indicates. I've put forth that it identifies a required set of metadata that might be extended; i.e., the version identifies the requirements, not necessarily the specific set of metadata in the message (which can be discovered by inspecting the message). This seems to have a nice interaction with the use of namespaces.

This doesn't seem to be what you have in mind. Could you give a straw-man rule of thumb as to when the version identifier should be changed, and what it identifies?

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