Re: Updated Versioning Strategies document

Dave:
My action was to review only sections 2 and 4 but I ended up reading the 
entire document in fair detail.

My initial reaction was surprise at the scope of the document. You 
address versioning of all (artificial) languages. With such a broad 
scope it’s difficult to make sharp recommendations. Thus, the first part 
of the finding reads like a tutorial on versioning. But then I got to 
section 5, which is focused on markup languages and their problems i.e. 
using existing software (browsers) with new versions of the language and 
the document got much more focused and useful.

Thus, the heart of the finding is section 5. So, I feel we should fix 
the earlier parts and state clearly our focus on markup languages and 
their problems.

Specific Editorial Comments

Abstract:

“Separate documents contain the terminology definitions and XML language 
specific discussion”. Please add pointers.

1. Introduction

1. The language should be extensible i.e. … (few words here)

2. “ … text of a language …” I don’t like this. Seems to talk about the 
documentation. Perhaps you mean “statements of a language” or “sentences 
in the language”

3. “ .. a given language version should define a set of compatible 
future version identifiers.” Hard to do since I don’t know what future 
versions of the language will contain.

1.2 Kinds of Languages

Bug in reference under bullet 3.

2.1 Why Have a Strategy?

“ … there are many messages that don't use any features of the new 
version or perhaps it is appropriate to simply ignore components that 
are not recognized.”

You have discussed only language text so far. Where do messages and 
components come in?

“Often, what is needed is some sort of middle ground solution.” What 
might such a solution look like?

Remainder of 2 and 4. You give examples of RSS and HTML but other 
examples of use/misuse of version numbers and other strategy would be 
really great! I realize this requires a great deal of work.

5. Java did remove features by marking them as ‘deprecated’and providing 
compiler warnings and then removing them in later versions.

At the end of the section you say “select one of the following 3 
alternatives” but there are only 2 alternatives. I prefer the second.

5.1 The SOAP MustUnderstand is not a language feature. It’s a directive 
to the processor.

“Choosing to ignore the container node only helped HTML considerably, 
but there are some elements who's children also should be ignored for 
rendering, particularly the /Script/ element.” I’m not sure what you 
meant to say. Is this sentence missing a “not”.

7. I would remove the last sentence. It seems to have a typo as well.

All the best, Ashok



Dave Orchard wrote:
> Based upon feedback from Noah, the TAG's Feb f2f, and phone 
> discussions with Noah.
> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies
> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-20080328.html
> These are now ready for review by Ashok, Dan, Noah, Norm, and Raman 
> per our agreements at the Vancouver F2F in 
> http://www.w3.org/2008/02/26-tagmem-minutes#ActionSummary
> Cheers,
> Dave


-- 
All the best, Ashok

Received on Sunday, 13 April 2008 19:56:41 UTC