Ashok's Versioning comments

 Great review, and thanks.  I'll be publishing a new version shortly. I've
snipped out the parts that I've agreed with.  I've put DBO>> to indicate my
responses.

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

DBO>>Much thanks!

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.

DBO>>I do disagree that this is just markup.  The guidance on planning for
forwards compatibility applies to any languages, including programming
languages and even URI construction, but we just use markup languages in our
examples.

1. Introduction

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

DBO>>Not sure what you want there.  I linked to our definition of
extensibility...

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"

DBO>>We've wrangled on this issue of texts of a language for 5 years now.  I
think it makes sense because we can talk about texts and set membership for
compatibility.

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.

DBO>> true, the whole point is that there are rules for how a consumer will
know whether a future version identifier is compatible or not.  The producer
will know what the future versions of the language will contain and they
will be able to determine the appropriate version identifier for the
text..

2.1 Why Have a Strategy?


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.

DBO>>I'm not sure which sections you are talking about.  2.1.1.1 for example
talks about XML, HTTP, XSLT.  4 talks about URIs and SSL..  Maybe I should
add some URI based examples in here...

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

DBO>> good point, I've added that in as well as the evolvability of feature
processing.

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.
DBO>> the 3rd is the sentence "We have observed that languages that are
successfully versioned are generally extensible".  I am personally strongly
against this 3rd option and a big proponent of the first.

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

DBO>>I don't see what needs to change in 5.1...

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

DBO>>parses right for me.  I changed the wording slightly to "Choosing to
only ignore the container node" and s/who's/whose/.