Solution proposal for versioning problem

[Jirka Kosek]

Norbert Bollow wrote:

> The fact is that backward incompatible changes, including the
> particuluarly dangerous kind of change which changes semantics
> without change of syntax, have occurred already, in the step
> between ECMA-376 ed 1 and ISO/IEC 29500:2008 Transitional.

Indeed, but we don't have time-machine, so we can't fix bad decisions
made in past.

> Adopting the convention that the year number in the namespace
> will be updated whenever a backward incompatible change occurs
> would be an acceptable solution for me, but from what I
> understood, it is not acceptable to everyone because it does
> not avoid the risk that existing ECMA-376 ed 1 or
> ISO/IEC 29500:2008 conformant applications might fail to load
> new documents that have the namespace name change just because
> of that.

I think this is true only for ECMA-376 applications failing to load
29500:2008 documents.

I think that any new features we are going to introduce in post
29500:2008 will be designed to be backward compatible itself or relying
on MCEs so there will be no need to change namespace.

> My current proposal provides specification version information
> while assuring existing ECMA-376 ed 1 or ISO/IEC 29500:2008
> conformant applications which do not understand the proposed
> versioning mechanism will not perform worse on existing documents
> because of that.

But what's the point of versioning information then? If we are going to
introduce versioning mechanism it should provide some advantages. But my
understanding is that for future versions of OOXML it should not be
necessary to use it and for past (and current) versions of OOXML it will
have no effect as already deployed applications will not understand to it.

				Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka at kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100708/9ffa9336/attachment.pgp>