What really can pollute a namespace are implementations of drafts
that never made it to RFC. If atom namespace is used for experimental
extensions, we are in danger of ending up with implementations "out
there" that misinterpret what the final RFC will say. *)
So, I think it is wise to publish all extensions in an own namespace
and switch that to atom (if desired) when the RFC gets final. James
proposal of a WG (or this mailing list for all practical purposes),
should then decide what to migrate to atom namespace and what not, so
that the terminology inside atom remains consistent and good to
understand.
//Stefan
*) Given the time periods necessary for pushing a spec to RFC, this
is more likely than not. If you really need a feature in your
product, you will ship implementations based on pre-drafts. And later
on you need to talk to these implementations...
(Just catching up on mail after vacation, so please excuse if I have
overreaad something.)
Am 07.01.2008 um 02:11 schrieb Mark Nottingham:
On 07/01/2008, at 11:46 AM, Bill de hOra wrote:
Mark Nottingham wrote:
The sentence afterwards is a bit more revealing;
The Atom namespace is reserved for future forward-compatible
revisions of Atom. Future versions of this specification could
add new elements and attributes to the Atom markup vocabulary
There are two ways to read this;
1) Future RFCs that completely replace RFC4287 are the only ones
allowed to add new elements and attributes.
2) Future RFCs that update RFC4287 are allowed to add new
elements and attributes.
Given that we allow pretty much anybody to rock up and add a link
relation with IESG approval, it doesn't seem like a far stretch
to me to say that #2 is the right reading, given that the only
real difference between the two is regarding document structure
(i.e., the whole doc + extension, or just extension).
In other words, by the logic of #1, the only thing James would
have to do is to copy RFC4287, add a section on tombstones, and
push it through the process. That seems pointlessly tortured, to
say the least.
I think the most you could say is that #2 needs IESG approval via
a standards-track RFC (again, notice the parity with the link
relation registry), but that's already assumed in the discussions
I've seen here.
But that's just my .02.
If there's a good technical or social reason to put tombstones
into the atom namespace, let's hear it.
As I think I said before, it's not a big deal either way; I just
don't want people to walk away thinking that *no* extension can be
in the atom namespace. Whether or not Tombstones in particular
belong in the Atom namespace is mostly a question of how common we
think they'll be once deployed, across a variety of use cases.
Personally, I think that there's potential for them to be widely
deployed across a number of use cases. In a way, both tombstones
and feed history feel like 'missing' parts of atom (but I realise
that from some perspectives, that can be said of almost any
extension).
Cheers,
--
Mark Nottingham http://www.mnot.net/
--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
