RE: First draft of TAG Blog Entry on Version Identifiers

Noah Mendelsohn:

in, third example:

| So, maybe I should label it 1.0? Unfortunately, that's a bit 
| hard for me. In 
| general, I would need to know the specifications for every 
| version of the
| language that's ever existed, so I could pick the oldest one 
| that's OK for
| my document. If the language has been revised a lot, that's 
| going to be
| difficult.

A rule of thumb would be to pick the oldest one *you know* accepts your
document. If you don't have the 1.0 specs, or don't care about 1.0 apps, use
2.0. If you really do want to support 1.0 apps, make the software more
sophisticated and use 1.0.

| Maybe the version attribute should take a list of versions, 
| and I should put
| in both 1.0 and 2.0? 

As you may know I've argued for the 'list' approach in XML.COM for
messaging, but for other scenario's (Tuna Salad Recipes, maybe HTML) this
solution may not be optimal.

| That could be helpful, but I probably 
| won't want to go
| back and fix it up if someone adds another backwards 
| compatible change to
| create a version 3.0 of the language...

That is never necessary. If 3.0 is backwards compatible with 1.0 and 2.0, an
3.0 app will know it may process 1.0 and 2.0 documents. Even with a list
approach the semantics of the version identifier should not be "past and
future compatible versions", it should either be "eldest known compatible
version" or "this version (the one used for writing), and all known prior
compatible versions".


Marc de Graauw

Received on Monday, 6 August 2007 21:33:57 UTC