RE: Version indicators (was Re: [public-webapps] Comment on Widget URI (7))

I'd be interested in your review of:

     http://larry.masinter.net/tag-versioning.html

I'm assuming the terminology and framework from that.



As for the utility of embedded global version indicators in various conditions and situations, I was hoping to push further on this. I agree that the evolution of implementations independent of specifications is only a factor, and that modularity causing combinations of multiple, independently evolving specifications, and the strategy for introducing incompatible  changes are also factors.



Languages evolve in different ways. For languages which

satisfy preconditions:



1. evolve slowly and carefully, so as to minimize the number of versions

2. there is a single specification which is first updated in standards groups, implemented carefully against the specification, with the specification finalized and implementations deployed only after testing against the specification

3. where the language has few or no dependencies on other specifications that are also evolving



Then single global embedded version indicator can be useful:



1. validators to know how to validate content against the intended version

2. in the unfortunate case of incompatibilities between versions, consumers can provide different behavior

3. for user agents to warn their users when receiving unknown versions

4. additional metadata for content management and retrieval



As the preconditions 1-3 are stretched, then the utility of a global inline version indicator is limited:



1.  Validators may validate against the indicated version, but most usefully will validate against the 'best' edition

2.  incompatible changes should be avoided because of the disarray

3.  new features should be introduced with fallbacks, so a warning against version incompatibility isn't very useful except perhaps in the case where the content received is otherwise nonsensical to the older interpreting softwar

4.  the metadata is less useful although might be used to drive evaluation of content updates



> So I don't think that it's a question of whether implementations drift

> compared to specifications - even though in practice that's a factor.



But if implementations are deployed before there are agreed upon

specifications, there is a serious problem, well beyond of "versioning".

This is a problem of chaos in the marketplace. Nothing a standards

group can do in advance can prevent multiple, incompatible implementations

from being deployed and content providers being eventually forced

to guess what the implementations are doing and send different content.

Certainly this isn't a situation to be celebrated.



> The problem is that using a version indicator is *not* a versioning

> strategy,



I agree completely. The utility of a version indicator varies

according to how the language actually evolves



> but as soon as you start having a versioning strategy you cease

> needing a version indicator.



I'm not sure how "having" a versioning "strategy" helps, much less

if you "start to have" one. I think part of what I was trying to

distinguish (which I don't see in your notes) is the difference

between "version of specification" and "version of implementation".

When you talk about "versioning strategy", I think most of the

things you talk about apply primarily to "specifications", but that

in some cases they also apply to "implementations", but if you

are careful to distinguish between them, a "versioning strategy"

might be an agreement of specification writers or organizations,

while what's needed is actually a binding commitment from

implementers, which is much harder to get.



Versioning in the web is much more complicated, because

there are many, many different technical specifications that

are brought together to create a single platform, including

not just HTML but CSS and JPEG and PNG and HTTP and URI and

JavaScript and etc and etc. Maybe 100 specifications all together.



The architectural principle common in standards (not just

in languages, but really in all industries, from food production

to manufacturing and telecommunication) is to use modular

specifications and in addition  "applicability statements"

or "profiles" which call out the versions of all of the

components.  The utility of a global version indicator in

this case is limited only because the indicator of a single

component is not sufficient to indicate the version of the

entire profile.



Larry

--

http://larry.masinter.net





-----Original Message-----

From: Robin Berjon [mailto:robin@berjon.com]

Sent: Monday, December 21, 2009 6:28 AM

To: Larry Masinter

Cc: Marcos Caceres; Marcin Hanclik; www-tag@w3.org

Subject: Version indicators (was Re: [public-webapps] Comment on Widget URI (7))



On Dec 18, 2009, at 17:22 , Robin Berjon wrote:

> On Dec 17, 2009, at 03:20 , Larry Masinter wrote:

>> I actually think the TAG discussions about versioning and the use of version

>> indicators has been helpful, but it's been hard to drive this to a publication,

>> because there's still some work to be done. However, I think the main insight

>> I've had is that version indicators have limited (but non-zero) utility in

>> situations where the popular language implementations evolve independently

>> of published language specifications. Normally, if language implementations

>> follow language specifications closely, you can use the version number of

>> the specification as a good indicator of the version number of the language.

>

> So I don't think that it's a question of whether implementations drift compared to specifications - even though in practice that's a factor. The problem is that using a version indicator is *not* a versioning strategy, but as soon as you start having a versioning strategy you cease needing a version indicator.



I've been editing an old paper about "XML Bad Practices" I'd presented at XML Prague last year and have been releasing it in small parcels[0]. There's a more detailed discussion of this specific topic at:



  http://berjon.com/blog/2009/12/xmlbp-naive-versioning.html



A longer and more thorough discussion of versioning strategies is certainly needed. It seems to me that we revisit it with every new working group :)



[0] http://berjon.com/blog/2009/12/xmlbp-intro.html



--

Robin Berjon - http://berjon.com/