Subject: RE: PaceMinimalVersioning

From: "David Orchard" <[email-masked]>
Date: Thu, 16 Sep 2004 09:12:11 -0700

I find PaceMinimalVersioning incomplete and inconclusive and found no
illustration or exploration of extension mechanisms.  

40% of PaceExtensibilityAndVersioning is explaining 7 different
scenarios and another 10% is discussing XML Schema's wrt extensibility
and versioning.  PaceMinimalVersiong does not address these issues or
provide scenarios. 

I can easily remove scenarios and schema, but I think they are important
to fully understand the extensibility and versioning impacts.  I would
have actually liked them to be even longer by having more detailed
examples in them.  

There's a number of other important areas that have been trimmed out,
which I'll detail later in this note.  

In general, saying that PaceExtensibilityAndVersioning is too long and
removing items and also proposing a different technique doesn't help
progress the key issues.  I'd like to focus on the inclusion or
exclusion of various items (like scenarios, xml schema, meaning of
"understand", what an "error is, etc.) separately from whether to use
version #s or not.  If you want version #s, please provide rationale on
why version #s are better than namespaces.  I provided one reason in
http://www.pacificspirit.com/blog/2004/09/02/problem_with_version_s

I can't tell whether you want a simpler Pace, or you want a simpler
extensibility/versioning strategy, or you want a different strategy.  If
you want a simpler pace, we can cut stuff.  If you want a simpler
ext/vers strategy, then we can do things like remove mU flag.  If you
want a different strategy because you think it is simpler, then let's
debate that.  

There are some main questions and decisions that I described in
http://www.pacificspirit.com/blog/2004/09/09/language%20choices%20decisi
ons%20scenarios

The three main questions/decisions that we are debating:
1. Can an extension author (that is not Atom) indicate that their
extension is mandatory/required?  I had understood this to be the case,
so I put in text for the mustUnderstand.  One way to "simplify" the
extensibility and versioning is to remove this.
2. What is the technique for Atom to indicate an incompatible version?
There are 3 choices: 
 a. use a new namespace name 
 b. use a version #.
 c. use mustUnderstand on the extensions.  Nobody is advocating this
because it, well, sucks.  
3. What is the technique for Atom to indicate a compatible version?
There are 3 choices: 
 a. use the same namespace name and no version #
 b. use the same namespace name and a version #
 c. use a new namespace name and no version #
 d. use a new namespace name and a version #

There are basically a small set of decisions that need to be made.  I've
argued that version # for incompatible versions is inappropriate and
I've provided rationale for that.   I've proposed 2a and 3a, but can
live with 2a and 3b though I still don't understand the rationale yet.
You've proposed using 2b and 3b and 3d without any justification.

PaceMinimalVersioning uses Section 4.1 version must-understand to
specify an extensibility model for all other elements and attributes, as
well as a processing model.  PaceExtensibilityAndVersioning specifies
the processing model in a separate section.  A processing model for Atom
should be in a separate section rather than buried in a particular
attribute definition because it spans particular attributes.

PaceMinimalVersioning doesn't describe the meaning and implications of
the version attribute and doesn't describe how an incompatible change in
atom is indicated.

PaceMinimalVersioning doesn't describe what "understanding" is in the
context of a mustUnderstand attribute. 

Cheers,
Dave  

> -----Original Message-----
> From: [email-masked] [mailto:owner-atom-
> [email-masked]] On Behalf Of Tim Bray
> Sent: Thursday, September 16, 2004 12:46 AM
> To: Atom-Syntax Syntax
> Subject: PaceMinimalVersioning
> 
> 
> I tend to agree with most of PaceExtensibilityAndVersioning, but I
> found it unnecessarily long and complex and did not find its
> exploration of extension mechanisms convincing.  So I decided to try
to
> create the Minimum Versioning Framework That Could Possibly Work, if
> only as a strawman.  -Tim
> 
> handy pointer:
> http://www.intertwingly.net/wiki/pie/PaceMinimalVersioning

---

From: Tim Bray <[email-masked]>
Date: Thu, 16 Sep 2004 09:50:06 -0700

> illustration or exploration of extension mechanisms.

PaceMinimalVersioning provides a simple, concrete, easily-implemented 
set of rules telling software exactly what it can and must do in the 
face of errors and unrecognized markup.  Perhaps you could outline a 
use-case in which it isn't crystal-clear what a software implementer 
can do and what someone sending Atom data can expect?

I further claim that to the extent you can decouple the extension 
mechanism from the handling of versioning and unrecognized markup, you 
win.  If someone wants to post another Pace describing extensibility 
mechanisms that allows the simple, unsurprising, easy-to-implement 
behavior specified in PaceMinimalVersioning, then that would be a very 
attractive extension mechanism.  And to the extent it requires anything 
more complex, I'm probably -1. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 16 Sep 2004 10:14:52 -0700 (PDT)

> illustration or exploration of extension mechanisms.

+1 

My original response said something similar but I
decided against posting it because some would have
considered it a 'flame'. 

> have actually liked them to be even longer by having

I'd suggest dumping the stuff about XML Schema. If
needed that stuff can show up in a primer or best
practices document. 
 
> extensibility and versioning is to remove this.

My preference is Yes but I have to admit there is no
precedent for this in RSS and at least one person on
this list has argued that he believes aggregators will
ignore it (which seems absurd to me but whatever). 

>  c. use mustUnderstand on the extensions.  Nobody is

C is definitely a non-started so I am amazed that
PaceMinimalVersioning seems to be implying that's what
Atom should do. 

Also I don't think 2a and 2b are exclusive. I believe
Atom should do both. 

>  d. use a new namespace name and a version #

My vote is 3b 
 
> I've provided rationale for that.  

I haven't seen this rationale, can you provide a link?

> I've proposed 2a
> and 3a, but can

I'm quite sure I posted a reason for doing 3b
yesterday. See
http://www.imc.org/atom-syntax/mail-archive/msg09964.html
in case you missed it. 

=====
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!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail