RE: Noah Mendelsohn Comments on July 26 Draft of TAG Versioning Finding

Hi Noah,

Some comments on your comments on the Draft Versioning Finding.

Noah:
| I think the finding needs to better separate the 
| compatibility of language versions from the compatibility 
| of various applications that consume those languages.

I agree. I think my example in my previous post
http://lists.w3.org/Archives/Public/www-tag/2006Aug/0104.html
shows this difference.

Short: if we have a language L1 which defines:
name = firstname, lastname, anything
and L2 defines:
name = firstname, lastname, middlename

Then L2 is forwards compatible with L1 (any L2 instance is an L1 instance)
but L2 is not backwards compatible with L1 (L2 cannot process an instance
which reads "Marc, de Graauw, 45" since it would expect a string after
lastname, not an integer.

So L1 and L2 are not both back- and forwards compatible.

However if we define an application A1 which sends:
name = firstname, lastname
but when receiving expects
name = firstname, lastname, anything

And A2 sends AND receives
name = firstname, lastname, middlename

then A1 and A2 are both back- and forwards compatible.

So the mechanisms which David describes ensure both back- and forwards
compatibility on the application level. A clear separation of language
compatibility vs. application compatibility would make the Draft clearer
without changing anything about the Best Practices which David is
recommending.

>From your second post:

Noah:
| it's the set of texts that's fundamental. The constraints 
| are just a convenient shorthand for letting you know what's 
| in the set.  

(Prime number example)

| Why my strong preference?  Given this formulation, the test 
| for membership 
| of a text is merely a set membership test.  With Dave's, you 
| need to test 
| set membership, then syntactic legality, then map, then test 
| semantics. It 
| has to be harder to reason about all that.

I agree with the notion that the set of texts in the language is important.
However I do not see whether it makes so much difference whether one
enumerates those or intensionally defines them. To me defining a language X
as:

X = {2, 3, 5, 7}
or
X = {x is a positive integer AND x is smaller than 10 AND x is a prime}
seems pretty much equivalent.

I guess the second is what David means when he says:
| I think the key part is that the set of texts may be
| determined by the constraints. 

However, it is true that one should not start with a set of texts bigger
than those in the language and then constrain this set, so:

X = {1, 2, 3, 4, 5, 6, 7, 8, 9}
constraint: texts must be prime numbers
is wrong. Constraints don't come on top of the set of texts, but they can
form an (non-enumerative) formulation of the set.

Noah:
| Similarly, in my approach, the test for language 
| compatibility can be a 
| simple superset relation on the texts, along with a test that the 
| information mapping is consistent.   

This point is important, but contains an unmentioned distinction: between
syntactical and semantical compatibility.

If an application A2 (say a word processor) is backward compatible with A1,
we expect A2 to correctly process all information in instances produced with
A1 both syntactically and semantically. I.e. if the A1 instance indicates
'Marc de Graauw' should be printed bold, we expect two things:
- A2 should not reject the instance, i.e. accept it as syntactically
correct,
- A2 should print or render 'Marc de Graauw' bold, i.e. correctly process it
semantically.

If A2 were to print or render 'Marc de Graauw' plain, or in italics, we
would not consided application A2 truly backwards compatible.

In forward compatibility, the situation is different. If A1 understands only
italics, not bold, and boldness is a new feature of A2, we expect A1 when
confronted with an A2 instance which says 'Marc de Graauw' should be printed
bold:
- A1 should not reject the A2 instance, i.e. accept it as syntactically
correct
- A1 should print or render 'Marc de Graauw' normally, certainly not bold,
i.e. we do not expect A1 correctly process the instance semantically, after
all, A1 does not understand boldness.

Common usage of the words forwards and backwards compatible is different
with respect to syntax and semantics. So the forwards/backwards relation is
symmetrical with respect to syntax, but assymmetrical with respect to
semantics. Of backward compatibility, we expect syntactical and semantical
correct behaviour, of forward compatibility, we expect only syntactical
correct behaviour.

What you name 'the test for language compatibility can be a simple superset
relation on the texts' is a test for syntactical compatibility, and 'a test
that the information mapping is consistent' is the test for semantic
compatibility.

The Draft never violates those principles, in fact the Must Ignore Unknown
is a way to state that semantical forward compatibility is not enforced.
However it is important to clarify the notions, since if semantical backward
compatibility is broken in a new version (which may happen when features
become obsolete), rolling out the new version needs special preparation,
whereas breaking semantical forward compatibility is pretty much the normal
case. If this distinction is made, then mustUnderstand flags can simply be
defined as a way to enforce semantical forward compatibility.

In a sense the fact that semantical forward compatibility is usually not
important, together with the distinction between language compatibility and
application compatibility is what makes the entire approach work.

Regards,

Marc

Received on Tuesday, 5 September 2006 10:23:33 UTC