Subject: RE: Extensbility and Versioning Paces

From: "David Orchard" <[email-masked]>
Date: Tue, 14 Sep 2004 10:52:19 -0700

I added some text on version attribute to
PaceExtensibilityAndVersioning.

A couple questions on delineation:
1) If Atom creates a backwards compatible extension and creates a new
namespace for these extensions but does not update the "atom schema" is
this extensibility or is this versioning?
2) What about case #1 where the "atom schema" is updated with the new
qnames?

I think that in the difference between extensibility and versioning in
the face of multiple namespaces being used by the spec owner is very
fuzzy.  Is this why some folks seem to be in favour of version numbers?

Cheers,
Dave

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Dare Obasanjo
> Sent: Sunday, September 12, 2004 4:01 PM
> To: Atom-Syntax
> Subject: Extensbility and Versioning Paces
> 
> 
> Short Version:
>  PaceAltExtensibilityAndVersioning -1
>  PaceExtensibilityAndVersioning    +0.5
> 
> 
> Long Version:
> 
> PaceExtensibilityAndVersioning
> ------------------------------
> PaceExtensibilityAndVersioning is about versioning yet
> it doesn't talk about how it relates to version
> attribute that exists on the atom:feed element. I also
> don't like the fact that this Pace doesn't make a
> clear delineation between extensibility and
> versioning.
> 
> PaceAltExtensibilityAndVersioning
> ---------------------------------
> The terminology of PaceAltExtensibilityAndVersioning
> is confusing in a number of places. The introduction
> talks about a version element but the text seems to
> reference a version attribute. I'm not really clear on
> what "namespace-qualified XML attribute content"
> means. Is that namespace qualified attributes or
> QNames in attribute values? Then there is the quote
> 'The namespace prefix for the core of Atom is
> described in the section titled "Notational
> Conventions". That namespace is unlikely to ever
> change.', I'm not sure if this is meant to be
> namespace name and not namespace prefix. There are a
> lot more of these haphazard uses of terminology which
> made it hard to grasp the core ideas of the Pace.
> 
> The proposed section 7.1 seems contradictory and hard
> to follow specifically
> 
> "Any future version of the Atom core that is backwards
> compatible with this version will use the same version
> string. An example is adding an optional element or
> attribute. The only time that the version identifier
> is expected to change is if elements are added to the
> core Atom, if any core element has an required
> attribute added, if any core element has an attribute
> removed, or if the required semantics of any part of
> an element in the core of Atom is changed."
> 
> So it starts of by saying that adding elements and
> attributes won't change the version number then
> immediately states that doing so does cause it to
> change. Which is it?
> 
> Then there's the fact that the fundamental premise
> seems to be that the namespace name shouldn't change
> but the version number should. I don't agree with this
> approach and state as much in the section "Version
> Numbers vs. Namespace Names" in the article at
> http://msdn.microsoft.com/library/en-us/dnexxml/html/xml07212004.asp
> 
> THe processing model in section 7.2 states
> 
> "- If it encounters unknown XML element content in any
> namespace where the atom:must-understand flag on the
> element is set to (or assumed to be) 'false', it MUST
> ignore it and all it's descendents."
> 
> The "or assumed to be" is ambiguous to me since it
> doesn't seem that there is an explicit statement in
> this Pace that defines when it is safe to "assume"
> that the atom:must-understand value is 'false'
> 
> 
> 
> 
> =====
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
> I will keep a special cache of low-tech weapons and train my troops in
> their use. That way -- even if the heroes manage to neutralize my
power
> generator and/or render the standard-issue energy weapons useless --
my
> troops will not be overrun by a handful of savages armed with spears
and
> rocks.
> 
> 
> 
> _______________________________
> Do you Yahoo!?
> Shop for Back-to-School deals on Yahoo! Shopping.
> http://shopping.yahoo.com/backtoschool

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 14 Sep 2004 15:28:58 -0700 (PDT)

> this extensibility or is this versioning?

You have loaded the question by calling them
'extensions'. The question is if v2.0 of Atom creates
new optional elements but puts them in a different
namespace, is that extensibility or versioning? 

If they are optional then there is no difference
between them and extension elements so I don't think
the answer to the question matters much except as a
philosophical discussion. 

> fuzzy.  Is this why some folks seem to be in favour

Version numbers provide a way to identify versions of
the format without resorting to changing namespace
names. The alternative is processing the document
until seeing some unknown but required element,
attribute or enumeration value. The process for
determinging whether an Atom feed can be consumed by a
client should be a simple check not read the entire
file until you see something weird. What if the weird
thing only shows up every couple of days in the feed? 

Given the above statement I definitely think the text
in section 7.2 

"Any future version of Atom that is incompatible with
this version will either use a different namespace
name or will use an element name not defined in this
specification. An example is adding a required
element/attribute or removing an element or
attribute."

should be tightened up. I don't think it should be an
either or situation. Backwards incompatible versions
must provide an explicit mechanism for stating they
are incompatible, clients shouldn't have to process
the entire message looking for stuff that they don't
understand. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2004 13:26:28 +0200

>thing only shows up every couple of days in the feed? 

Are you saying that we should have absolute requirements in the Atom
format specification that define how implementations must determine
whether they can process the document? In a number of discussions on
this list I read from implementers that whatever we might write into
the specification they will just do their own thing which they think
suits their users best. Why would implementers write their software
so that it rejects specific Atom documents based on e.g. a version
number? It seems that users rather desire that they are not required
to upgrade their reader whenever some of their feeds upgrade to a new
version of Atom, so, how is a version number better than die hard
attempts to process at least parts of the content? We do have ultra-
liberal parsers already, no?

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 05:37:08 -0700 (PDT)

--- Bjoern Hoehrmann <[email-masked]> wrote:

> whether they can process the document? 

Yes. 

> In a number
> of discussions on
> suits their users best. 

Yes. 

> Why would implementers write
> their software

Atom is not only a syndication format that will be
used on the World Wide Web for reading blogs. It is
also an format that will be used by as a paylod in the
API for content management systems (or is the ATOM API
dead?). Also many may want to syndicate important
information (e.g. when Atom was being formed Tim Bray
talked about banks syndicating credit card
transactions via XML syndication feeds) where there
needs to be strictness in ensuring that there will not
be data loss when data is exchanged between parties. 

It's one thing to use an ultra liberal parser when
reading what John Doe had for breakfast in his blog
and another to say its OK to drop information when I'm
reading data about my credit card transactions from my
bank or when I'm posting a number of trip report from
customer vistits to my company's CMS. 

=====

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2004 15:03:07 +0200

>customer vistits to my company's CMS. 

Aha, so are you suggesting that we should have different conformance
requirements for these different classes of implementations? Or do
you mean that we should write anything into the specification that
makes us feel good even if we know that many if not a majority of
clients are just going to ignore it?

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 06:12:36 -0700 (PDT)

> clients are just going to ignore it?

Nobody will be 100% conformant to a spec. The goal of
the spec should be to tell people what the best
behavior should be. The best behavior in the face of
content that says "if you don't understand how to
process my content then error" is to error. 

Now you can argue that some people will write code
that ignores mustUnderstand semantics to which I would
probably agree. However this does not mean that Atom
should not have a mechanism for supporting them which
is one of the things you seem to be implying. 

On the options you provide on what we should do 

1.) Different profiles of Atom - I've always felt that
there should be different profiles of the Atom format
since some uses need more information than others
(e.g. archival has different needs from syndication
which has different needs from the API). However I
don't think we should have Atom Strict and Atom Lax
syndication formats. That seems excessive

2.) Write stuff in the spec that we know people will
ignore - Based on experience with RSS it is a given
that people will ignore certain aspects of the spec.
I'm pretty sure there will be aggregators that won't
key off the namespace URI but will only use the local
name of elements when processing Atom. There will be
liberal XML parsers. There will be consumers that
won't error if mandatory elements are missing from the
feed. This is a given. Does this mean Atom shouldn't
use XML namespaces or that there should be no
mandatory elements in the spec? 

=====

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2004 16:09:53 +0200

>is one of the things you seem to be implying. 

Mark Baker gave an example where he would like to depend on the proper
implementation of a feature, ignoring the must-understand semantics for
his example would be harmful, depending on how common it is to ignore
these special semantics he might not be able to use the feature at all.

And it is not only Mark who desires interoperability in this case, Atom
implementers that follow the spec and correctly implement the must-
understand semantics might be faced with Major Atom Implementation that
ignores it and users complain that this Atom implementation is much
better than theirs as it makes such content accessible to them. They
might have to change their product to be non-comformant in order to
compete. I do not desire that Atom implementations compete on such
grounds. And Mark does not either, it seems.

But I do not worry much about must-understand semantics for some entries
which then might be ignored, I rather worry about requirements to ignore
entire feeds based on e.g. version numbers, namespaces, or MIME types. I
might be wrong but my impression is that

>mandatory elements in the spec? 

it is rather unlikely that such requirements would be followed. I think
indeed that we should avoid requirements that will be ignored by many
implementations. A commonly ignored requirement is useless for practical
purposes and might even be harmful as it confuses people who did not
reverse engineer lots of implementations to see how to interoperate with
them. Does it buy you anything if the Atom 1.0 specifaction requires to
ignore a feed with version='2.0' but all Atom implementations process it
anyway?

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 07:18:19 -0700 (PDT)

I think mustUnderstand is important and you think
people will ignore it so it is useless. I guess we
know each other's position. 

I'm done with this particular thread since it is clear
we aren't going to convince each other to change our
positions and I have an XML 2004 submission to finish.

Thanks for clearly stating your opinions on this
issue.  

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 15 Sep 2004 11:50:01 -0400

On Wed, 15 Sep 2004 16:09:53 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
> better than theirs as it makes such content accessible to them.

I'm sure that would never happen.  Developers have always cared more
about standards than their own customers, and users have always cared
more about interoperability than minor features like receiving
content.

-- 
Cheers,
-Mark

---

From: Mark Baker <[email-masked]>
Date: Wed, 15 Sep 2004 13:11:25 -0400

Erm, I think you guys are missing the whole point of mandatory
extensions.  If un-extended processing were sufficient to
communicate what the publisher is trying to communicate, then
the extension would not be mandatory.

FWIW, I don't ever expect to see them used for human-targetted
content.  My "truthValue" example would be an exception, but that's
rather far fetched, I'm sure you'd agree.

Mark.

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