Subject: RE: Version vs. Namespace

From: "David Orchard" <[email-masked]>
Date: Mon, 12 Jul 2004 09:17:50 -0700

What kind of an answer is this? "No, it's hard?" 

Who said anything about Atom solving the versioning problem in the general case?  And btw, what ARE the versioning use cases of Atom?  I've started writing up some work on Atom extensibility/versioning, but it's become a bit hard because it seems like everything could be extended/versioned...

Tim, you should know as well as anybody, that the problems of figuring out what a "version" of a mixed namespace document is can rarely be done with a single integer.  What does a "version" mean under distributed and multi-ns extensibility?

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.

Cheers,
Dave 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Tim Bray
> Sent: Sunday, July 11, 2004 10:11 PM
> To: Atom Syntax
> Subject: Re: Version vs. Namespace
> 
> 
> 
> On Jul 11, 2004, at 5:43 PM, Mark Nottingham wrote:
> 
> > In other words, I'm proposing that we refine our approach to 
> > versioning to three separate things:
> 
> I'm massively unconvinced that this added complexity has noticeable 
> benefit.  I want to see a single namespace that means "this is Atom", 
> and I don't expect the semantics of atom:title to change for a long 
> time so I don't think its name should change, and I do want a 
> root-level "version" attribute.  Going down the path of solving the 
> versioning problem in the general case reliably leads to convulsions 
> and hairy palms.  Let's do the simplest thing that could 
> possibly work: 
> a fixed namespace and a root version attribute. -Tim
> 
>

---

From: Mark Baker <[email-masked]>
Date: Mon, 12 Jul 2004 13:11:35 -0400

I was just about to say the same thing.  +1

---

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

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 11:32:58 -0600

Personally I like the idea of using profiles as opposed to version 
numbers.  The issue is in determining which profile a particular feed 
validates against.  However, one could easily imagine various profiles 
based on specific use cases of the syntax, where each profile determines 
which extension elements to expect in the feed, strict definition of 
various optional elements, etc.  Yes, it does add a bit of complexity, but 
I believe the benefits would be significant.  I do not believe, however, 
that the core specification should define normative profiles.  Profiles 
should be submitted as separate RFCs.  The core spec could specify the 
process of creating profiles.

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

Mark Baker <[email-masked]> 
Sent by: [email-masked]
07/12/2004 10:11 AM

To
David Orchard <[email-masked]>
cc
Atom Syntax <[email-masked]>
Subject
Re: Version vs. Namespace

On Mon, Jul 12, 2004 at 09:17:50AM -0700, David Orchard wrote:
> Who said anything about Atom solving the versioning problem in the 
general case?  And btw, what ARE the versioning use cases of Atom?  I've 
started writing up some work on Atom extensibility/versioning, but it's 
become a bit hard because it seems like everything could be 
extended/versioned...
> 
> Tim, you should know as well as anybody, that the problems of figuring 
out what a "version" of a mixed namespace document is can rarely be done 
with a single integer.  What does a "version" mean under distributed and 
multi-ns extensibility?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 11:10:32 -0700

Well, at least one profile needs to ship with the core spec, so that 
people have something to grab onto and get interop with. Whether that 
lives in the same document or somewhere else is just a packaging issue.

There's already been some related discussion that shouldn't be lost:
   http://www.imc.org/atom-syntax/mail-archive/msg04336.html
   http://www.imc.org/atom-syntax/mail-archive/msg06262.html

On Jul 12, 2004, at 10:32 AM, James M Snell wrote:

> based on specific use cases of the syntax, where each profile 
> determines which extension elements to expect in the feed, strict 
> definition of various optional elements, etc.  Yes, it does add a bit 
> of complexity, but I believe the benefits would be significant.  I do 
> not believe, however, that the core specification should define 
> normative profiles.  Profiles should be submitted as separate RFCs. 
>  The core spec could specify the process of creating profiles.
>
> - James M Snell
>   [email-masked]
>   http://www.ibm.com
>   (877) 511-5082 / Office
>   930-1979 / Tie Line
>
>
>
>
> general case?  And btw, what ARE the versioning use cases of Atom? 
>  I've started writing up some work on Atom extensibility/versioning, 
> but it's become a bit hard because it seems like everything could be 
> extended/versioned...
>  >
>  > Tim, you should know as well as anybody, that the problems of 
> figuring out what a "version" of a mixed namespace document is can 
> rarely be done with a single integer.  What does a "version" mean 
> under distributed and multi-ns extensibility?
>  >
>  > 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 

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

---

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

> lives in the same document or somewhere else is just a packaging 

I would like Atom 1.0 to be minimal and finally tuned, to the extent 
that it only includes things that basically everyone would use.  Done 
that way, it would not need a profile.  I see a profile as an admission 
of bloat.  I think that if, for any feature, you could say "that 
wouldn't be in the basic profile", then it should be taken right out of 
Atom. -Tim

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Jul 2004 13:19:01 -0600

+1 on this.  The base Atom specification is itself the "basic profile" and 
should be as minimal with as few optional components as possible.  The 
most that the basic specification should say about profiles is that 
profiles may be defined that detail how non core-elements (e.g. elements 
from other namespaces) should be used within given contexts (use cases) 
and specify that such profiles should be submitted as separate RFC's.

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 12:51:40 -0700

On Jul 12, 2004, at 11:40 AM, Tim Bray wrote:

> that way, it would not need a profile.  I see a profile as an 
> admission of bloat.  I think that if, for any feature, you could say 
> "that wouldn't be in the basic profile", then it should be taken right 
> out of Atom. -Tim

I agree that the metadata that ships with Atom should be minimal and 
finely-tuned.

I disagree that the requirements for the presence of that metadata 
(e.g., "MUST have a title") should be set in stone for all things 
called "Atom 1.0." There are other uses of the Atom format that won't 
care a whit about the title, and they shouldn't be forced to use it.

Perhaps you misunderstand what I mean when I say "profile." It's not an 
exclusive device (at least, in the core); it doesn't say "you don't use 
these extensions" or "you can only use this handful". Rather, it's a 
set that can be built upon; It's "you MUST have one of these and one of 
those, and you can have other stuff too."

I agree that an exclusive profile in Atom 1.0 would be an admission of 
bloat, but that's not what's on the table here. What's on the table is 
a way of factoring out the requirements pertaining to the presence of 
particular pieces of metadata in feeds and entries.

Moreover, much the same could be said about a "version" attribute; it 
allows the same kind of flexibility. Why don't you consider the version 
attribute bloat? All that calling this a profile does is allow us to 
organise the spec in a clearer, more helpful and extensible way; e.g.,

Atom Container Constructs
    atom:feed
    atom:entry

Atom Metadata Constructs
    atom:author
    atom:title
    atom:content
    ...

Atom Core Profile
    MUST have a title, etc.

---

From: "Andreas Sewe" <[email-masked]>
Date: Mon, 12 Jul 2004 22:25:21 +0200

Mark Nottingham wrote:
> 3) The "package" of metadata used in a feed is described by a "profile"
> or "version" attribute, e.g.,
>    <atom:feed profile="http://.../..."> ... </atom:feed>
>    Atom would ship with a "default" profile that says there MUST be an
> atom:title, etc. -- just as the spec currently does -- and that
> extensions are allowed on top of that. More specialised vertical uses
> of Atom can likewise describe their own profiles; if they can get tool
> support for them, good on them.

FYI, the "application/xhtml+xml" media type registers an optional profile too
[1] such that e.g. content negotiation can rely on the profile as well. And at
least for "application/smil+xml" there are plans to add a profile parameter to
the registered media type as well [2].

I hope this helps.

Regards,

Andreas Sewe

[1] <http://www.rfc-editor.org/rfc/rfc3236.txt>
[2] <http://www.w3.org/2002/06/registering-mediatype#Status>

---

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

--- James M Snell <[email-masked]> wrote:
> > that it only includes things that basically
> everyone would use.
>
> should be as minimal with as few optional components
> as possible.  

+1 from me as well.

=====
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!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

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

--- Tim Bray <[email-masked]> wrote:
> architecture that we understand the implementation
> issues.  

I tend to agree with you.

> clear sense of exactly what the complexity buys us. 

My primary use case for versioning is simple. How can
an aggregator which encounters a different version of
Atom from one its seen before know whether it is
backwards compatible or not? With RSS, the assumption
I use in RSS Bandit is that all feeds are RSS 2.0 and
the version attribute is ignored. I'd like Atom to
have something formal about what aggregators like RSS
Bandit should do to be able to distinguish Atom 0.3
from Atom 1.0 [for example]. 

=====

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 17:14:54 -0700

On Jul 12, 2004, at 2:47 PM, Dare Obasanjo wrote:

> the version attribute is ignored.

I'd like to make this a bit more concrete.

0) Let's imagine that Atom 1.0 has been released and finalised in all 
of its glory.

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.

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.

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.

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.

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.

Any proposal for versioning should address at least these situations, 
show how the various extensions and changes are identified and 
disambiguated, and should explain how software is to handle them. They 
should also consider how combinations of these scenarios are handled.

> I'd like Atom to

That is a problem that we should not attempt to address; pre-draft 
versions of Atom are not for deployment, and anyone who does so in a 
non-experimental manner is taking all of the risk upon themselves. The 
final release of Atom will, at least, be identified by a different 
namespace URI, so that should be sufficient.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jul 2004 18:03:25 -0700

At 5:14 PM -0700 7/12/04, Mark Nottingham wrote:
>0) Let's imagine that Atom 1.0 has been released and finalised in 
>all of its glory.
>
>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 
>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.
>
>atom:title that is backwards-compatible, just *better*. It gets 
>really popular, and yet another version of Atom is born.
>
>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.
>
>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.
>
>Any proposal for versioning should address at least these 
>situations, show how the various extensions and changes are 
>identified and disambiguated, and should explain how software is to 
>handle them. They should also consider how combinations of these 
>scenarios are handled.

+1 or more. This is an excellent mix and not at all far-fetched. It 
should help us focus on what we need for versioning and extensibility.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Mark Baker <[email-masked]>
Date: Mon, 12 Jul 2004 21:53:23 -0400

> [1] such that e.g. content negotiation can rely on the profile as well. And at

FWIW, that was just a hack to handle the explicit case mentioned in
there (negotiation for XHTML Basic), and because at the time of the
registration, there were competing wireless negotiation specs, neither
of which had reached critical mass and could therefore not be counted
on to handle this form of negotiation.

Profiling HTML was generally acknowledged to be a waste of time in most
cases.  Consider that text/html used to have two different parameters
for this purpose ("level" and "version") and both were dropped because
nobody used them; developers simply preferred to make use of the
(mustIgnore-laden) extensibility model associated with the media type,
and that worked just fine.  I fully expect that to be the case for Atom.

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

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

---

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

> and that worked just fine.  I fully expect that to be the case for 

I don't share your conviction; the use cases for Atom are quite 
different. Atom is not a presentation format, it's a metadata 
container, and something that allows people to group together different 
types of metadata into a single package will engender interoperability 
and functionality.

We already have one profile of Atom -- the blog/newsfeed profile that 
is the direct successor to RSS. That's great, but part of the reason I 
find Atom so exciting is that it can enable other profiles too; for 
example, stock price feeds, weather feeds, CVS changes, etc. ad 
infinitum. Individual extensions aren't enough to enable these uses 
because it ignores the combination of extensions that characterises a 
particular application.

---

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

On 12 Jul 2004, at 10:31 pm, Mark Nottingham wrote:

> container, and something that allows people to group together 
> different types of metadata into a single package will engender 
> interoperability and functionality.
>

I'm not liking this profile talk. Are you suggesting a newsreader would 
have to explicitly support the stock price profile or the weather 
profile, to be able to show it? As I've said before, I thing the 
content/summary elements should be presentation-orientated, with 
machine readable versions in extensions. That way you don't need 
profiles.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 20:06:10 -0700

On Jul 12, 2004, at 7:54 PM, Graham wrote:

> Are you suggesting a newsreader would have to explicitly support the 
> stock price profile or the weather profile, to be able to show it?

Not at all; it's just a mechanism to allow people to identify packages 
of metadata to code to and write feeds to.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 04:22:00 +0100

Mark Nottingham wrote:

> We already have one profile of Atom -- the blog/newsfeed profile that is 
> the direct successor to RSS. 

I thought that *was* Atom.

> That's great, but part of the reason I find 
> Atom so exciting is that it can enable other profiles too; [snip].

RDF/XML already enables this.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 20:32:34 -0700

> RDF/XML already enables this.

RDF/XML is nearly universally abhorred; even the Semantic Web's most 
starry-eyed promoter would have a hard time loving it.

I have no quarrel with the RDF model (actually, I love it to death), 
but please, don't hold up the RDF/XML syntax as something to emulate or 
consider as an alternative. "Worst of both worlds" pops into the mind, 
as does "DOA."

Just my .02, of course.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 04:52:22 +0100

Mark Nottingham wrote:

> I have no quarrel with the RDF model (actually, I love it to death), but 
> please, don't hold up the RDF/XML syntax as something to emulate or 

Well, thanks, but you're preaching to the choir. I have a history of 
objection to RDF/XML.

But it remains a fact that RDF/XML enables this; and Atom does not.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Jul 2004 22:01:49 -0600

> --Internet Mail Consortium

Agreed.  Fundamentally, the first and foremost thing that we should focus 
on is determining how difficult this WG wants to make it to allow such 
changes to occur and whether or not changes should be defined so that they 
are backwards compatible.  I do not believe it would be too far fetched 
for this group to assert that changes should be absolutely backwards 
compatible unless it can be demonstrated that the a breaking change is 
absolutely required.  Let's set the bar high right from the beginning.

Regarding #2, introducing an "extension namespace" where such new elements 
can be defined, experimented with, implementation practice/experience 
gained, etc, would greatly enhance the process.  When a new element is 
proposed, it would be put into the extension namespace initially.  Only 
after it has been implemented and folks agree that it is essential to have 
as part of the core would it be placed under the core namespace.

Regarding #4, allow people to come up with whatever extension elements 
they wish in their own namespace and define that all elements in unknown 
namespaces are to be summarily ignored and dismissed.  If the creators of 
those extensions wish to define a profile for their use, let them go 
through the work of writing up an RFC that describes the appropriate 
semantics.  Once the RFC is published, Aggregators and other apps can 
choose whether or not to support that RFC.

Whether or not Atom's versioning of the core spec gets out of control is 
more a function of this groups philosophy towards accepting changes of 
dubious or unproven utility.

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 21:11:26 -0700

> Well, thanks, but you're preaching to the choir. I have a history of 

Always good to add to the multitude -- must be quite a sound by now!  ;)

> But it remains a fact that RDF/XML enables this; and Atom does not.

Aha; I see your point. Atom isn't final, so I don't think we can make 
such statements about it yet. If people seriously want to make Atom a 
one-shot, one-scenario spec (i.e., blogging/news feeds), we need to get 
consensus around that. I, for one, would object violently.

Cheers,

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Jul 2004 22:31:20 -0600

> consensus around that. I, for one, would object violently.

+1.  Atom needs to be usable across many different syndication apps

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

---

From: James M Snell <[email-masked]>
Date: Mon, 12 Jul 2004 22:28:27 -0600

[email-masked] wrote on 07/12/2004 09:01:49 PM:

> Agreed.  Fundamentally, the first and foremost thing that we should 
> focus on is determining how difficult this WG wants to make it to 
> allow such changes to occur and whether or not changes should be 
> defined so that they are backwards compatible.  I do not believe it 
> would be too far fetched for this group to assert that changes 
> should be absolutely backwards compatible unless it can be 
> demonstrated that the a breaking change is absolutely required. 
> Let's set the bar high right from the beginning. 
> 
> Regarding #2, introducing an "extension namespace" where such new 
> elements can be defined, experimented with, implementation 
> practice/experience gained, etc, would greatly enhance the process. 
> When a new element is proposed, it would be put into the extension 
> namespace initially.  Only after it has been implemented and folks 
> agree that it is essential to have as part of the core would it be 
> placed under the core namespace. 
> 
> Regarding #4, allow people to come up with whatever extension 
> elements they wish in their own namespace and define that all 
> elements in unknown namespaces are to be summarily ignored and 
> dismissed.  If the creators of those extensions wish to define a 
> profile for their use, let them go through the work of writing up an
> RFC that describes the appropriate semantics.  Once the RFC is 
> published, Aggregators and other apps can choose whether or not to 
> support that RFC. 
> 

You know, after going back and reading this and reading the rest of the 
thread, I retract part of this.  The use of the MustUnderstand attribute 
is a far better approach.  I would, however, definitely like to see a 
tiered approach to changes made to the core namespace.

<atom:feed xmlns:atom="..." xmlns:atomex="...">
  <atom:title>...</atom:title>
  <atomex:core-extension atom:MustUnderstand="true" />
  <abc:other-extension atom:MustUnderstand="false" />
</atom:feed>

The creation and modification of elements in the abc namespace are 
arbitrary.  Anybody can do that any time they wish.

The creation and modification of elements in the atomex namespace would 
require that an RFC be submitted to this working group.  As long as the 
RFC has been published and is available for discussion, the element can 
automatically go into the atomex namespace.

The creation and modification of elements in the atom namespace would 
require first that the changes be defined within the atomex namespace 
(e.g. have an RFC submitted) and have achieved consensus within this WG 
that the changes are critical to the core spec.

Following this approach *should* help to mitigate the types of issues 
enumerated above.

> Whether or not Atom's versioning of the core spec gets out of 
> control is more a function of this groups philosophy towards 
> accepting changes of dubious or unproven utility. 
> 
> 
> - James M Snell
>  [email-masked]
>  http://www.ibm.com
>  (877) 511-5082 / Office
>  930-1979 / Tie Line

---

From: Dan Brickley <[email-masked]>
Date: Tue, 13 Jul 2004 05:36:04 -0400

* Mark Nottingham <[email-masked]> [2004-07-12 19:31-0700]

> because it ignores the combination of extensions that characterises a 

I took this particular extensibility discussion to be about the
evolution of the core Atom namespace, ie the rules for interpretation of 
incrementally added atom:* XML elements and attributes. I share your
excitement about stock prices, job listings, movie locations etc
appearing in feeds, although to date Atom is a technical step backwards
from what we had in RSS 1.0 in that regard: Atom optimises for the
blogging use case (very nicely) but doesn't yet have anything that
gives rules for the sane combination of independent extension vocabs.

It does seem reasonable to deal with internal-to-Atom extensions before
attempting to deal with the bigger problem spaces of namespace-extended
Atom extensibility.

On that front, I'm still trying to figure out what "must ignore" means;
to an Atom2XHTML XSLT filter, "must ignore" might mean "pass it through", 
to an Atom search engine, "must ignore" might mean "don't match against user
searches". In other words "must ignore" doesn't make much sense to me
without a taxonomy of Atom implementation types. FWIW when we were
discussing this in the RDF design, we backed away from that approach
(except, to some extent, re parsers) and talked instead about 
extensions being "additive" (or monotonic [1]). This is just a mathsy
way of saying that extensions only add information, and don't interact
with each other in fiddly and hard to predict ways. But then RDF has a
very passive-voice, declarative perspective on things; Atom markup (at
least in the core Atom namespace) might have more operational aspects.
Which is why splitting things out into core-Atom extensibility versus
other-namespace extensibility seems useful to me here. 

Dan

[1] http://www.w3.org/TR/rdf-mt/#MonSemExt

---

From: Dan Brickley <[email-masked]>
Date: Tue, 13 Jul 2004 05:50:23 -0400

* Mark Nottingham <[email-masked]> [2004-07-12 21:11-0700]
> Always good to add to the multitude -- must be quite a sound by now!  ;)

To be clear, the objection is to RDF's XML syntax, rather than to the
RDF effort as a whole?

A while ago, some of us sketched out what Atom feeds might look like in
an alternative, unstriped, XML encoding of RDF. Actually we used the 
SOAP Encoding syntax; jumping from one unloved XML graph notation to another ;)

http://esw.w3.org/topic/SpotOfDrama
http://esw.w3.org/topic/AtomJobExample

This is an "unstriped" RDF syntax in the sense of
http://www.w3.org/2001/10/stripes/ ie. that XML elements always stand
for edges in the RDF graph (ie. properties, relations), rather than
sometimes that, and sometimes for classes/categories.

I'm circulating it not as a concrete suggestion for adoption, just to
show that RDF can be used to support a namespace extension model for
Atom without necessarily adopting the RDF/XML syntax rules.

cheers,

Dan

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 11:27:23 +0100

> To be clear, the objection is to RDF's XML syntax, rather than to the

Objection to RDF's XML syntax. There are a number of mappings of 
Atom onto RDF - the one I did required some 'extra' inference around 
author and relating entries to a feed, but hasn't dealt with content 
yet.

cheers
Bill

---

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

/ Mark Nottingham <[email-masked]> 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 <[email-masked]> | Most human beings have an almost
http://nwalsh.com/            | infinite capacity for taking things for
                              | granted.--Aldous Huxley

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 13 Jul 2004 09:20:23 -0400

> I'd like to make this a bit more concrete.

Thanks for setting this conversation on solid ground.
I've tried to fill out the examples using Tim's model.

> 0) Let's imagine that Atom 1.0 has been released and finalised in all

<feed version="1.0" xmlns="atom" ...
   <title>My Stuff</title>

> backwards-compatible with the old one.

I would argue against making  a non-backward compatible
change to an element. How about 
introducing a new 'super-title' element in a 2.0 release:

<feed version="2.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>

> "fog." So, a new version of Atom is introduced.

<feed version="3.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>

> popular, and yet another version of Atom is born.

Note that title and super-title are both
legal but 'super-title' is depracated.

<feed version="4.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>

> the WG, but these are destined to remain separate.

All of these go in their own namespaces. It is up to 
the authors of those extensions to flag which 
versions of Atom that they interoperate with.

<feed version="4.0" xmlns="atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>
   <foo:bar/>

> Another Version of Atom (YAVA) comes into being.

That is a rather fundamental change for which I would hope
you would select another namespace and mime-type:

<notfeed version="1.0" xmlns="something-besides-atom" ...
   <title>My Stuff</title>
   <super-title>My Extended Stuff</super-title>
   <fog/>
   <foo:bar/>

> should also consider how combinations of these scenarios are handled.

Tim's policy seems to work, but with the following caveat/addition:

1. Newer versions of the format are kept backward 
compatible with older versions. Note that in these examples that 
was done by not changing an element in a non-backward compatible 
way but by introducing a new element. Note that in step 1.0 the
'super-title' could have also been introduced as 'title' but in
a different namespace. If you must break 
backward compatibility do it in a new format/namespace/mime-type.

I will also note that the use of mustUnderstand is not 
of use in any of the above scenarios. Are there other 
formats where 'mustUnderstand' semantics have been
successfully deployed? I don't think SOAP's history 
with mustUnderstand is one to point to as representing
'success'. [1]

[1] http://www.pocketsoap.com/weblog/soapInterop/base.html

    Thanks,
    -joe

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 14:34:48 +0100

> compatible with older versions. 

Yes, I think that is entailed by rules 3 and 4 (they seem to 
conflict/fail without it).

The idea is of adding new element names or QNames rather than 
altering existing ones approaches what Dan Brickley described as 
"monotonic" elsewhere... and on that, I would be happy to see a 
versioning rule/policy that new elements (from any namespace) added 
to new version will not affect the expected behaviour over previous 
elements and versions, ie there's no versioning approach that 
involves/encourages co-occurence constraints between elements; but I 
have no idea how to test for it (except maybe trying to write it 
down in xsd).

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 14:52:03 +0100

>   atom:title and use the atom:summary for the title instead.)

I would like to see this extended for elements in the atom 
namespace,, or at least make the hurdle to getting this by very high.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2004 10:18:46 -0700

Thanks, Norm - comments / questions inline.

>   atom:title and use the atom:summary for the title instead.)

Agreed.

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

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

>   - Unrecognized elements in the Atom namespace or any other

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

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

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

> Bump the version identifier. No problem.

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

> do, and applications that don't, don't.

Yes.

> That's just 1 or 2 again, depending on whether or not the change is

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?

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 13:58:05 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| Thanks, Norm - comments / questions inline.
[...]
|> - 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.)?

I think we mean any element, not just the children of feed and entry.
I should be allowed to do this:

  <atom:entry>
    <atom:title>Hello <foo:world atom:mustUnderstand="true"/></atom:title>
    ...
  </atom:entry>

even if it's really stupid :-)

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

I'm not sure exactly what your asking. My intent is that the former
case is an error. A processor should have the freedom to reject feeds
that are in error. However, if it doesn't reject the feed, it must
proceed by ignoring the error. The latter case isn't an error at all,
it's just an unrecognized extension (and unrecognized extensions must
be 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.
|
| Yes, as long as they don't have a mustUnderstand=true flag.

Right. That was a general rule I made at the beginning.

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

If it gets a new namespace URI, it just becomes an extension element.
If it gets a new local name, then you have to bump the version number.

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

If we want to be able to add elements without changing the version
number, then we can't make unrecognized elements in the Atom namespace
be an error. I think it's useful to make them errors because it
catches typos and various other sorts of problems that will otherwise
be silently ignored.

In my view, a feed validator ought to be able to complain about:

  <feed version="Red">
    <entry>
      <lnk rel="start" href="xxx"/>
      ...
    </entry>
  </feed>

if it knows what's valid in "Red" (and "lnk" isn't valid).

If it has never heard of version "Red", then it shouldn't complain
(except perhaps informationally) because it has to assume that "lnk" is
allowed in that version.

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

Well, you said it was "backwards-compatible". I assume it has *some*
new semantic or it wouldn't just be backwards-compatible, it would
be "the same as" :-)

If you want processors to be able to take advantage of the new
semantic, you have to give them some clue about it :-)

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

The version identifies the RFC to which the feed purports to conform.
It identifies exactly which elements in the Atom namespace are legal
and exactly where they are allowed to occur and what semantics they
have.

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

If the RFC is revised in a backwards-compatible way, the version number
has to change. If the RFC is revised in a backwards-incompatible way,
it better define a new namespace.

Does that help?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | The happiest people seem to be those
http://nwalsh.com/            | that have no particular reason for
                              | being happy except that they are
                              | so.--W. R. Inge

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2004 17:12:11 -0700

On Jul 13, 2004, at 10:58 AM, Norman Walsh wrote:

>     <atom:title>Hello <foo:world 
> atom:mustUnderstand="true"/></atom:title>
>     ...
>   </atom:entry>
>

OK. Does this mean that extensions (as well as core metadata such as 
atom:title) need to define where mU is allowed in their domains, or is 
is expressly allowed anywhere? If the latter, I'm not so concerned 
about the stupid angle (always hard to rule out), but it seems like it 
might be an implementation burden (e.g., <html:b 
atom:mustUnderstand="true">foo</html:b>).

> If it gets a new local name, then you have to bump the version number.

I see - this codifies the specialness of the Atom namespace by tying it 
to the version; the version declares definitively what's allowed in the 
Atom namespace.

> catches typos and various other sorts of problems that will otherwise

OK, this is the heart of the matter, and motivates a lot of your design.

> if it knows what's valid in "Red" (and "lnk" isn't valid).

Clarification: is "link", for the purposes of this example, in the atom 
namespace, or some other one? I.e., does the version also allow you to 
talk about what's allowed (and not) from other namespaces?

> (except perhaps informationally) because it has to assume that "lnk" is

Right.

> semantic, you have to give them some clue about it :-)

This seems like another axis of things that the version identifier can 
talk about. Could you (or anyone else) give a concrete example of an 
element that exhibits this kind of change?

> it better define a new namespace.

Very much so, thanks.

---

From: Norman Walsh <[email-masked]>
Date: Wed, 14 Jul 2004 08:58:05 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| On Jul 13, 2004, at 10:58 AM, Norman Walsh wrote:
|
|> I think we mean any element, not just the children of feed and entry.
|> I should be allowed to do this:
|>
|>   <atom:entry>
|>     <atom:title>Hello <foo:world
|> atom:mustUnderstand="true"/></atom:title>
|>     ...
|>   </atom:entry>
|>
|> even if it's really stupid :-)
|
| OK. Does this mean that extensions (as well as core metadata such as
| atom:title) need to define where mU is allowed in their domains, or is
| is expressly allowed anywhere? If the latter, I'm not so concerned
| about the stupid angle (always hard to rule out), but it seems like it
| might be an implementation burden (e.g., <html:b
| atom:mustUnderstand="true">foo</html:b>).

Uhm. I think the latter, but all we can say in the spec is that it's
allowed on all the atom: elements and that processors must look for it
on all elements. Whether it's actually allowed on elements in the
norm: namespace is up to the person that defines it.

| I see - this codifies the specialness of the Atom namespace by tying
| it to the version; the version declares definitively what's allowed in
| the Atom namespace.

Right.

|> In my view, a feed validator ought to be able to complain about:
|>
|>   <feed version="Red">
|>     <entry>
|>       <lnk rel="start" href="xxx"/>
|>       ...
|>     </entry>
|>   </feed>
|>
|> if it knows what's valid in "Red" (and "lnk" isn't valid).
|
| Clarification: is "link", for the purposes of this example, in the
| atom namespace, or some other one?

In this example "lnk" is in the Atom namespace and is probably a typo
for "link" (also in the Atom namespace) if version "Red" is known not
to allow "lnk".

| I.e., does the version also allow
| you to talk about what's allowed (and not) from other namespaces?

I don't think the version has any bearing on what's allowed (or not)
From other namespaces. We say explicitly that anything's allowed.
I suppose we could say in some future version that elements from
the norm: namespace are forbidden, but I don't imagine we ever will.

The version tells you what RFC to read. The RFC tells you the syntax
and semantics. Anything you can get consensus to write in the RFC you
can control with the version attribute.

|> |> | 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?
|>
|> Well, you said it was "backwards-compatible". I assume it has *some*
|> new semantic or it wouldn't just be backwards-compatible, it would
|> be "the same as" :-)
|>
|> If you want processors to be able to take advantage of the new
|> semantic, you have to give them some clue about it :-)
|
| This seems like another axis of things that the version identifier can
| talk about. Could you (or anyone else) give a concrete example of an
| element that exhibits this kind of change?

I can contrive one, but I can't think of any natural and useful ones
off the top of my head.

We could add a new atom:initials element to atom:name to allow a feed
to identify the initials of a person. This is a backwards compatible
change to atom:name because an old processor can just ignore the
initials element. But we want new processors to be able to do
something with it. By changing the version, a new processor can know
that the atom:initials element means what the new RFC says it means
and that it should really be there (it isn't a horrible misspelling of
"email").

                                        Be seeing you,
                                          norm

(All of this discussion is still ignoring some nasty details about how
these compatible changes can be expressed in XSD. And I think we
should continue to do so until we figure out what our policy is going
to be, but after we decide what we really want the policy to be, we're
going to have to talk about expressing it (or not) in a schema
language.)

-- 
Norman Walsh <[email-masked]> | Some people can stay longer in an hour
http://nwalsh.com/            | than others can in a week

---

From: Ian Davis <[email-masked]>
Date: Wed, 14 Jul 2004 16:45:04 +0100

> I'd like to make this a bit more concrete.

I think some, maybe all, of these could be handled using OWL constructs.

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

Create a new namespace with copies of all elements. Write an OWL schema 
that declares all elements except atom:title to be owl:equivalentClass 
or owl:equivilentProperty to the relevant element in the in Atom 1.0 
namespace.

Consumers use the schema to define rules in their applications, either 
dynamically or just by hard coding them after readint the schema. When 
the application looks  for particular elements it must also look for 
those that have been declared equivilent to the element they need.

Use owl:DeprecatedClass or owl:DeprecatedProperty to declare that 
previous atom:title has been retired.

Use owl:incompatibleWith on the schema to declare that new version of 
Atom is not backwards compatible. Consumers now should be aware that 
semantics of Atom may have changed.

An addition of an optional element is a non-breaking change so add it to 
current namespace. Use owl:backwardCompatibleWith to declare that new 
version of Atom is in every respect backwards compatible.

If element is non-optional, it's a breaking change so use 
owl:incompatibleWith instead.

Create a new namespace. Declare all equivilent elements in the same way 
as scenario 1. Declare oldatom:title to be a subClassOf newatom:title, 
i.e. every oldatom:title is a newatom:title but not every newatom:title 
is an oldatom:title since the new one is *better*.

Use owl:backwardCompatibleWith on the schema to declare that new version 
of Atom is in every respect backwards compatible.

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 create a new namespace and their own OWL schema. They're free to 
subclass or equate any elements they want.

New namespace, new OWL schema. Use owl:incompatibleWith.

Just one way to do it I'm sure.

Ian