[www-tag] <none>

[Larry Masinter-3]

Re the widget: scheme
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0115.html
http://www.w3.org/TR/2009/WD-widgets-uri-20091008/

(bcc www-tag since original call was; there's an AWWW suggestion
buried in here somewhere, though)


1) ** WELL DEFINED QUERY AND AUTHORITY **
http://www.w3.org/TR/webarch/#URI-scheme points to RFC 2617, which has been
replaced by RFC 4395. I think WebArch should be updated to recommend that
W3C recommendations must use "permanent" schemes and not "provisional" ones.

RFC 4395 requires that permanent scheme definitions be "Well-defined". Leaving in syntactic components and declaring them "out of scope"  is leaving them undefined.

Suggestion: Remove 'authority' from the syntax, and any sections that
  refer to them; disallow query components
Alternate Suggestion: define the meaning of "authority" and query components.

2) ** WELL-DEFINED MAPPING TO FILES **

Section 4.4 Step 2 makes normative reference:

http://www.w3.org/TR/widgets/#rule-for-finding-a-file-within-a-widget-

The algorithm there seems to be lacking a clear definition of "matches"
which deals reasonably with the issues surrounding matching and equivalence
for Unicode strings, or the handling of character sets in IRIs which are
not represented in UTF8.

Suggestion (Editorial): Move the definition of the mapping algorithm
into the URI scheme registration document so that its definition can
be reviewed for completeness.
Suggestion (Technical): Define exactly and precisely what "match" means
and make it clear what the appropriate response or error conditions are
if there is more than one file that "match"es.

3) ** Reuse URI schemes **

http://www.w3.org/TR/webarch/#URI-scheme includes   "Good practice: Reuse URI schemes"

"A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources."

The draft suggests there are many other schemes (with merit) already proposed, but that these existing efforts, "rather than identify packaged resources from the outside, widget URIs identify them only on the inside of a package, irrespective of that package's own location.", but this seems to indicate that the requirements for "widget" URIs are weaker, not stronger.

Suggestion: Supply use cases where reuse of existing schemes (including "thismessage:/") do not provide the desired properties of identifiers and their relation to resources.
Alternate Suggestion: Withdraw registration of "widget:" and reference existing scheme.
Alternate Suggestion: Provide guidelines so that "widget:" can be used for other applications
  that need a way of referencing components within ZIP packages; rename "widget:" to use
  a scheme name that is appropriate for this broader application.

AWWW Suggestion: add guideline: "Make New URI Schemes Reusable If You Can't Reuse URI schemes".

4) ** EDITORIAL RE OTHER SCHEME  **

"In fact, it is possible that both this scheme and another defined to access Zip archive content would be used jointly, with little or no overlap in functionality."

Without any other context, this is incomprehensible.

Suggestion: remove sentence.

5) ** EDITORIAL USE OF URI FOR IRI **

"Throughout this specification, wherever the term URI [URI] is used, it can be replaced interchangeably with the term IRI [RFC3987]. All widget URIs are IRIs, but the term URI is more common and was therefore preferred for readability."

Seriously, do we need a W3C Guideline or Finding to cover "DO NOT REDEFINE TERMS"?
There's glory for you! (see http://www.sabian.org/Alice/lgchap06.htm ).

Suggestion: Use "IRI" since that's what is meant.

6) ** EDITORIAL RE FRAGMENT **

"Note that assigning semantics or interpretation to the query or fragment components is outside the scope of this specification. The ways in which they are used depends on the content types that they are applied to, or what executable script decides to do with them."

The wording might be taken to mean that a URI scheme registration normally *does* assign semantics or interpretation to the fragment components.

Suggestion: drop this note.


7) ** EDITORIAL TITLE **
"Widgets 1.0: Widget URIs" the "1.0" might imply some kind of versioning, but there is no versioning of URI schemes.

Suggestion: retitle "Widget URIs"


8) ** EDITORIAL DOCUMENT ORGANIZATION **

Are "A, B, C and D" appendices? Normative?  
Suggestion: remove A ("Usage as Origin") either remove B ("Requirements") or edit it to be comprehensible to someone not familiar with the widgets specification, make C ("Acknowledgements") and D ("References") into normal document sections.

9) ** ORIGIN CALCULATION **

A: "Usage as Origin"
This information applies to the notion of origin calculation which is itself incomplete, and introduces an unnecessary normative dependency.

Suggestion: Drop this section (if needed for widgets, put it somewhere
else)

[Larry Masinter-3]

(bcc public-webapps since not as relevant)

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.

However, in situations like HTML, where the implementations have evolved
-- and are likely to continue to evolve -- independently of the versions
of the specifications (and each other), the utility of a version indicator
is more confusing. Users would *like* a version indicator to correspond
to a category of implementation, but the only thing we can give version
numbers to realistically are versions of specifications instead. So the
utility is limited to controlled situations where the producer of the document
with a version indicator really carefully intends to note a specification
version, or to cause validation against a particular specification.

I'm not quite sure what "P&C" is, to know how this analysis applies to it.

Larry
--
http://larry.masinter.net

-----Original Message-----
From: Marcin Hanclik [mailto:Marcin.Hanclik@...]
Sent: Wednesday, December 09, 2009 1:37 PM
To: Larry Masinter; Robin Berjon
Cc: public-webapps@...
Subject: RE: [public-webapps] Comment on Widget URI (7)

Hi Larry,

WOW:
It's a pity you were not involved in the discussions around P&C's version attribute.

Thanks,
Marcin
________________________________________
From: public-webapps-request@... [public-webapps-request@...] On Behalf Of Larry Masinter [masinter@...]
Sent: Wednesday, December 09, 2009 7:20 PM
To: Robin Berjon
Cc: public-webapps@...
Subject: RE: [public-webapps] Comment on Widget URI (7)

FWIW, just to be clear:

My comments about versioning and version numbers only apply
to the URI scheme, and not to language specifications in
general.

I haven't reviewed any of the other WebApps documents,
except in the context of reviewing the URI scheme.

In general, I support appropriate use of version numbers in
languages and language specifications, especially since
documents and file formats have ample opportunities for
in-band version indicators. It's unfortunate that URIs,
being compact strings, have no place for version indicators.

Larry
--
http://larry.masinter.net


-----Original Message-----
From: Robin Berjon [mailto:robin@...]
Sent: Thursday, November 19, 2009 4:08 AM
To: Larry Masinter
Cc: public-webapps@...
Subject: Re: [public-webapps] Comment on Widget URI (7)

Dear Larry,

thank you for your comments.

On Oct 10, 2009, at 19:44 , Larry Masinter wrote:
> 7) ** EDITORIAL TITLE **
> "Widgets 1.0: Widget URIs" the "1.0" might imply some kind of versioning, but there is no versioning of URI schemes.
>
> Suggestion: retitle "Widget URIs"

I have provisionally made this change. I agree with Marcos that it would be good to do so throughout the widget family of specifications, especially since there is no reason why versions of its various components need to evolve in synchronised fashion - one could use P+C 4.2 with WARP 2.7.

Recommendation to the WG: apply the same change throughout.

--
Robin Berjon - http://berjon.com/





________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

[Marcos Caceres-3]

On Thu, Dec 17, 2009 at 3:20 AM, Larry Masinter <masinter@...> wrote:

> (bcc public-webapps since not as relevant)
>
> 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.
>
> However, in situations like HTML, where the implementations have evolved
> -- and are likely to continue to evolve -- independently of the versions
> of the specifications (and each other), the utility of a version indicator
> is more confusing. Users would *like* a version indicator to correspond
> to a category of implementation, but the only thing we can give version
> numbers to realistically are versions of specifications instead. So the
> utility is limited to controlled situations where the producer of the document
> with a version indicator really carefully intends to note a specification
> version, or to cause validation against a particular specification.
>
> I'm not quite sure what "P&C" is, to know how this analysis applies to it.
>

Sorry, P&C is the "Widget Packaging and Configuration" specification:

http://dev.w3.org/2006/waf/widgets/

--
Marcos Caceres
http://datadriven.com.au

[Robin Berjon-2]

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.

That's not how I would characterise it. For error-handling and versioning purposes, you can get much, much more mileage out of defining processing rules (ignore-unknown, must-understand, etc.) than you get out of version indicators — especially given the fact that if you produce a truly incompatible new version of a given language, you really should just change the namespace.

Once you have bi-compatible processing rules, and a contract that breaking changes must lead to a new language (because conceptually, if it's not mutually intelligible, it really is a different language), well you quickly find that any version indicator is either a) correct, but entirely useless; or b) incorrect (and therefore potentially harmful).

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'm not quite sure what "P&C" is, to know how this analysis applies to it.

P+C is the Packaging and Configuration widgets specification, which defines an XML language that has no version indicator (some people asked for one, but no one could demonstrate a use for it) but does have a set of ignore-unknown versioning (and extensibility) rules. It has been shown to be trivially grown and extended without compatibility issues nor version indicators.

--
Robin Berjon - http://berjon.com/

[Robin Berjon-2]

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/

[Larry Masinter-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...]

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

To: Larry Masinter

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

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/

 

 

 

[Robin Berjon-2]

Hi Larry,

On Dec 22, 2009, at 03:42 , Larry Masinter wrote:
> I'd be interested in your review of:
>      http://larry.masinter.net/tag-versioning.html

The first thing that jumps up at me is:

"Right now, new HTML features seem to be deployed on the web by HTTP servers "sniffing" the User Agent identifier (consumer capability) and using it to determine which edition of a HTML page should be generated for that consumer."

While UA sniffing is done in places (perhaps most systematically in mobile content adaptation), it is not the most common path for the introduction of new features and I don't believe I have seen many advocate it as best practice. New HTML features tend to be deployed using various techniques for (more or less) graceful degradation such as shims or fallback. That is to say: the exact same content is sent from the producer to all consumers, but the consumers exhibit different behaviours (not using the font but still showing the text, losing interactivity or decorations, emulating the intended behaviour but with strongly diminished performance, etc.).

This is important because it alleviates the need for "new or otherwise unrecognized consumers" to indicate that they support a given set of features. Any form of negotiation introduces a new axis of complexity in the production of content. I think that a sound architectural principle is that interoperability should require as little negotiation between agents as possible, ideally none.

Now I will readily admit that the techniques I mention above are also a form of negotiation; shims say "Ooh! I see you don't support this, let me add it for you", fallback says "you don't understand this? Use that". But compared to out-of-band negotiation which applies to the entire document and deals in broad feature-sets such as "versions" or "agents", these negotiation techniques can be characterised as being "in situ" in that they happen in the proximity of what they affect, and "scoped" in that they (typically) apply to a single feature — both of these properties make them far less complex and far more manageable than global negotiation.

Therefore I would further define the architectural principle outlined above: the "little" in "as little negotiation as possible" is most usefully measured in terms of proximity to the effect (i.e. avoid "Action At A Distance") and affected feature surface area.

Of course there is a limit: at some point if you start having to rely on too many small negotiations you are better off with a single larger one.

For our purposes we can posit that all languages will have a language indicator (media type, root element local name, DOCTYPE, namespace, magic number, file extension, sniffing — it doesn't matter). I think that it is a sound principle that a language indicator should apply to all variants of that language which are "mutually intelligible" (in the linguistics sense) but only to those.

If {Unicorn, 1.0} and {Unicorn, 1.1} are mutually intelligible, then negotiation on the delta of their feature sets can (and should) be localised. In this case a version indicator is too broad a negotiation tool to be useful and can be dropped. It is just the Unicorn language.

If {Unicorn, 1.0} and {Unicorn, 2.0} are not mutually intelligible, then they have no business sharing a name. They could be just Unicorn1 and Unicorn2, or Unicorn and ChupaCabra.

That's in essence what I'd vehicle to working groups when it comes to version indicators: either you don't need them, or they're the wrong solution. However do define a strategy that allows for mutual intelligibility across versions (the truly hard part, that the TAG would IMHO be most helpful with if it were to tackle it), and if it comes to incompatibility then do change the language indicator.

Note that the "Unicorn" language indicators I use above are the technical indicators: for marketing purposes companies (and groups) could of course keep calling their products "Unicorn" while the indicator moved from application/cryptid-1 to application/cryptid-2.

> 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

In all honesty, I am very much unconvinced that we can produce sound architectural advice based on the above preconditions. The problem I see here is that all of these are backwards-looking (i.e. inductive) whereas the primary goal of a versioning architecture is to provide future-proofing.

It may be that a language has evolved slowly and carefully over the past decade, but that all of a sudden an innovation in another part of the stack opens up a whole swathe of previously impossible or impractical yet justified and valuable features. There may have been a single specification for a length of time, but a rift in the industry causes work on different aspects to be split; or groups at the edges become frustrated with the sluggish progress at the core and produce splinter extensions. The language may have dependencies on things that have long seemed stable and reliable, but that are now brutally changing under one's feet (e.g. the introduction of Unicode). Also, group membership changes over time. The group may have started off as a measured consensus of wise people, but as people have moved on and new ones been drawn in it is now comprised mostly of rowdy fourteen-year-olds eager to change the world.

I contend that a solid versioning strategy (or in fact, any architectural advice) has to be resilient in the face of such changes. If version indicators are predicated on groups and specifications being slow and careful, then they shouldn't be used. If anything, we standards-makers should distrust ourselves — that's how strong constitutions are built.

You list some interesting use cases:

> Then single global embedded version indicator can be useful:  
>  
> 1. validators to know how to validate content against the intended version

I think that looking at this through version indicators is doing it wrong: this is a limitation of schema technology that altogether too often fails to take versioning into account as a founding parameter. I would like a schema language which can be decorated with information about the seventeen specification versions of my language and that instead of returning a boolean valid/invalid for a given document would say:

  - this document is feasibly valid for specification versions 1 through 8 through the application of the ignore-unknown rule to features (and be able to list which features would which version);
  - this document is strictly valid from version 9 on.

Or state that it is invalid at any version level.

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

What I am missing here is the reason why one would not just change the language indicator in such a case.

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

I think that this is probably best addressed through a must-understand flag. Sometimes I may use a new element and if you ignore it I don't care. Sometimes I may use the same element and provide a fallback. And at yet other times I might be using that element and the document is meaningless without it. I only want the agent to warn the user if it's the latter (e.g. I'm sending a legal document and interpretation of the whole is necessary). Version indicators don't have the granularity to handle this.

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

Indeed it isn't. I completely agree that if there is outright chaos then there is nothing that we can do. However I'm sure we both agree that interoperability is only rarely near perfect, that specifications are never perfectly clear, and therefore that there will be some amount of drift, and therefore a little amount of chaos.

I believe that strategies to handle these (hopefully) small deltas amongst implementations (both in content and in future revisions to the specification that take the drift into account) are the same as those that make for a good versioning strategy (localised negotiation) — and again that version indicators are too crude an implement to address these.

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

I do not make the distinction between specification and implementation when discussing versioning strategies because I do believe that such a strategy is so fundamental to the design of a language that it has to be accepted in full by both parties — without that you cannot usefully evolve your language, or at the very least it becomes baroque as happened with quirksmode. This further entails that the adopted strategy should be as simple as possible.

I don't disagree that it's much harder to get — but it is so important that if the specifiers cannot obtain that from implementers then that community is in trouble.

The compact as it were is that:

  - specifiers define a versioning strategy (i.e. an algorithm for the processing of unknown language constructs) that implementers commit to (preferably as early as possible), and which is thoroughly tested in the test suite;
  - specifiers commit to producing new features in such a manner that the versioning strategy guarantees graceful degradation (or to clearly create a new language if they don't).


This discussion reminded me of a specification specimen that I believe is interesting in the context of this specification:

  SVG Tiny 1.2 — Appendix C. Implementation Requirements
      http://www.w3.org/TR/SVGMobile12/implnote.html

If we look at this appendix and compare it to what happens in effect:

  - Section C.2 defines a simple versioning strategy that doesn't necessitate version indicators. This part works, and is implemented.
  - Section C.4 defines a number of behaviours based on version and profile indicators; to the best of my knowledge no one has implemented that, or even cares.

I'm do not necessarily intend to use the fact that one is implemented and not the other as an argument here (though it is a data point) but rather I think that this wild specimen is a good example in that C.4 is not actually useful in the presence of (the much simpler, clearer) C.2.

[Full disclosure: I wrote the original proposal that became C.2, and fought a losing battle against keeping C.4 in after it had proven useless in 1.1; other (former) members of the SVG WG may therefore have different analyses.]

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

Certainly. That's why I think that the more localised the versioning/negotiation toolset the better. Just imagine having a version indicator for the compound language that is the whole web stack!

--
Robin Berjon - http://berjon.com/