DR-08-0012: Preventing a slippery slope

Alex Brown alexb at griffinbrown.co.uk
Mon Jun 1 11:36:08 CEST 2009


Dear all,

> Over lunch today I spent some time thinking about versioning 
> based on our earlier conversation today.  I found the 
> documents that Gareth and Alex mentioned very insightful ( 
> thank you ).  I know we've all been tasked with going back 
> and doing some deeper thinking about versioning - which I'll 
> do - but I wanted to test a best principle of mine regarding 
> the evolution of the standard.  I've always been of the 
> opinion that as the standard evolves, new features should be 
> added in a backward compatible way ( using a variety of 
> pre-existing technologies such as OPC, MCE, extLst, etc. ) 
> and that breaking changes would be very rare.
>
>  Since any 
> deeper thinking on versioning on my part would be based on 
> this premise, I wanted to verify if folks in WG4 saw things similarly.
> 

I suspect, in general, most XML experts would agree with this. Making
breaking changes "does evil to the ecosystem" and so is best avoided.
Having said that though, even successful formats usually evolve to a
point where their maintainers judge a breaking change is worthwhile.
Think, for example, of DocBook, NLM, or HTML -- and ODF is scheduled for
a breaking change in its ODF-Next release. Of course, not all of the
breaks have been well done -- so there are lessons there for us.

Personally, I'd agree the Namespace change for S *is* a rare kind of
thing.

> I put DR-08-0012 in the subject line because I could see a 
> logical argument being made that if we were willing to break 
> the namespace, "anything goes."

Well, the format is formally under control of the NBs and we must assume
they reflect the interests of their user constituencies (in very
different ways). I would think it very unlikely for those constituencies
to want to make capricious breaking changes, or indeed any kinds of
breaking change that were not thoroughly justifiable. I'd have though
"justifiable" reasons for breaking changes might be things like (a)
risks of data losss (as we see), (b) that the standard is
unimplementable in certain respects, (c) to remove intrinsic features
which disenfranchised certain communities. It's hard to imagine concrete
examples in all these cases.

> I believe that this would be 
> an extreme mistake for the standard.  And so I wonder if we 
> ought to put text into the response for DR-08-0012 explaining 
> the extra-ordinary circumstances behind this change and 
> explicitly call out that this should change not be used as 
> justification for additional breaking changes.

I'd have thought not. Although of course we (WG 4) can adopt whatever MO
we want for our work, I don't believe we should attempt to fetter the
discretion of future WG 4 groups of experts to make decisions based on
their best judgements in accord with their NBs interests. I also think
it might be unwise to put out a ballot document which might be
interpreted as attempting to constrain NB's future decision-making
processes.

- Alex. 



More information about the sc34wg4 mailing list