Proposed Response to FPDAM Part 1 BR-0001, et al

[Alex Brown]

Dear all,

This is not quite right as a response, I think.

First, WG 4 has not "concluded" that we should not add versioning to 29500. My recollection is that in Prague we decided to park that discussion and focus on the immediate issues raised by the Swiss comments. I think it would be more accurate to state that this topic is still being studied in WG 4.

Secondly, I'm not sure it's a good idea to list technologies that we use for versioning, either - partly because this risks confusing versioning technology with extensibility mechanisms, and partly because it might be seen to bind us to a certain approach. Stating that we are using Namespaces (a very blunt instrument) for our major changes is potentially a hostage to fortune.

Of course it _may_ be that we conclude not to add any (more) versioning mechanisms to OOXML.

However, I think it is also likely that we may want to add rich semantics to help consumers know precisely what it is they are consuming - this includes version information but is not limited to it: we may wish to convey information about the status and version of extensions being included, for example.

And if we decide to make first-class changes to the schemas, I believe we may need a versioning mechanisms then. So if (as seems likely) there is a move to amend 29500 to remove CustomXML, how will we convey to consumers that they are consuming resources that conform to this amended spec? We're not going to make another global Namespace change are we?

Until we have thoroughly explored these kinds of issues, I propose responding as follows:

"WG 4 is still studying the topic of versioning in general, and BR is encouraged to participate in those discussions. The current amendment is focused on addressing the particular versioning issue raised  CH, and does not preclude further work in this area."

- Alex.

From: Shawn Villaron [mailto:shawnv at microsoft.com]
Sent: 22 January 2010 21:56
To: SC 34 WG4
Subject: Proposed Response to FPDAM Part 1 BR-0001, et al

Good afternoon,

Here is my proposed draft response for this series of comments.  Comments welcome, as always.

shawn

WG4 Response

Rejected.

WG4 has conducted extensive research into versioning technology associated with ISO/IEC 29500.  Our conclusions are that, absent a clearly specified, unsupported versioning use case, additional versioning technology should not be added to ISO/IEC 29500.  The potential consequences of introducing a flawed versioning technology clearly outweigh any potential benefits.

Furthermore, ISO/IEC 29500 already supports a number of different mechanisms to enable many versioning scenarios.  Here is a sampling of such mechanisms:


*         XML Namespaces - Provides for "major" version increments that are not designed to be backward compatible with existing implementations.

*         Extension Lists - Provides for adding orthogonal data in predefined locations within the XML.  See Part 1.

*         Parts - Provides for adding entirely new payloads into the file container.  See Part 2.

*         Alternative Content Blocks - Provides for adding multiple renditions anywhere in the XML.  See Part 3.

*         Ignorable Namespaces - Provides for adding orthogonal data anywhere in the XML.  See Part 3.

Given these, and other, mechanisms currently provided for in ISO/IEC 29500, and that such mechanisms provide support for the known versioning use cases, WG4 does not believe we need a new versioning technology.  We continue to evaluate new versioning-related use cases, and in the event we find one which cannot be supported by existing versioning technologies, we will consider adding additional versioning technology at that time.



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100204/a2434c7e/attachment-0001.htm>