<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:989871005;
mso-list-type:hybrid;
mso-list-template-ids:-2114653512 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Here’s what we concluded:<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:#1F497D'>WG4 Response for BZ-0001 and CH-0001<o:p></o:p></span></b></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Rejected.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>WG4 does not believe we need a new versioning technology as a solution to differentiate Ecma 376 First Edition from ISO/IEC 29500:2008-T. Simply adding a new version attribute at this time requires adding it as an optional attribute or a required attribute. If we add the version attribute as an optional attribute, we are essentially replicating the optional conformance attribute which was added at the BRM; alternatively, if we add the version attribute as a required arttribute, we break existing files and implementations. Given these trade-offs, we concluded that addding a version attribute was the wrong solution to this problem.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>It is also worthwhile to note that we have proactively addressed differentiating Strict and Transitional files via the FPDAM by changing the namespace for Strict files.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='color:#1F497D'>WG4 Response for DE-0001<o:p></o:p></span></b></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Accepted.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>ISO/IEC 29500 already supports a number of different mechanisms to enable many versioning scenarios. Here is a sampling of such mechanisms:<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>• XML Namespaces – Provides for “major” version increments that are not designed to be backward compatible with existing implementations. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>• Extension Lists – Provides for adding orthogonal data in predefined locations within the XML. See Part 1.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>• Parts – Provides for adding entirely new payloads into the file container. See Part 2.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>• Alternative Content Blocks – Provides for adding multiple renditions anywhere in the XML. See Part 3.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>• Ignorable Namespaces – Provides for adding orthogonal data anywhere in the XML. See Part 3.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Alex Brown [mailto:alexb@griffinbrown.co.uk] <br><b>Sent:</b> Thursday, February 04, 2010 7:35 AM<br><b>To:</b> Shawn Villaron; e-SC34-WG4@ecma-international.org<br><b>Subject:</b> RE: Proposed Response to FPDAM Part 1 BR-0001, et al<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Shawn, all,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>I think </span><span style='color:#1F497D'>versioning and extensibility _<i>can be</i>_ intertwined, but that’s a particular approach and whether it applies to 29500 depends to a large extent on how the S/T discussions are concluded. One view might be that OOXML is “versioned” through standardizing extensions; another is that the core schemas themselves are versioned and extensions remain a discrete class of thing, inside or outside the standard. We haven’t decided which of these (or other) approaches to take yet.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Some topics (like versioning of extensions) we haven’t yet touched yet, so far as I can remember.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>It’s probably not fruitful to discuss the i4i thing here (or in the disposition), but if we imagine that – for valid or invalid reasons – it is decided that CustomXML has to come out of the Standard, then we will be faced with exactly the kind of versioning problem that a version-via-extension technique would not cater for very well.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I’m certainly not against taking strong positions where we have them: but my impression is that WG 4 doesn’t have a strong position here. I believe we have solved some immediate problems with this amendment, and that we have answered the Swiss comment – but I don’t believe we yet have a good story to tell about versioning and extensions in all respects – and so I don’t want us to say that we have.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Or is it just me?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>- Alex.</span><span lang=EN-GB style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"></a><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Shawn Villaron [mailto:shawnv@microsoft.com] <br><b>Sent:</b> 04 February 2010 14:16<br><b>To:</b> Alex Brown; e-SC34-WG4@ecma-international.org<br><b>Subject:</b> RE: Proposed Response to FPDAM Part 1 BR-0001, et al<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I would assert that versioning and extensibility are inherently intertwined and hence I think it’s important to educate the various groups what technical tools we have at our disposal. I’m not sure that that ties our hands in any way – it just says that, as of today, these are the tools in our toolbox and our understand of how we’d use them. It doesn’t say that we can’t acquire more tools or find new uses for the existing tools. It’s merely an observation at a point in time. I really don’t think that this restricts us at all.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>The CustomXML comment is a complete red herring … i4i doesn’t apply at all to this standard and hence there is no reason that we should be considering removing it. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I’m still baffled why we’re afraid to take a position here. We’re willing to take lots of strong positions elsewhere. Why are we scared when it comes to “versioning?”<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Alex Brown [mailto:alexb@griffinbrown.co.uk] <br><b>Sent:</b> Thursday, February 04, 2010 2:15 AM<br><b>To:</b> e-SC34-WG4@ecma-international.org<br><b>Subject:</b> RE: Proposed Response to FPDAM Part 1 BR-0001, et al<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Dear all,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>This is not quite right as a response, I think.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Of course it _<i>may</i>_ be that we conclude not to add any (more) versioning mechanisms to OOXML.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>Until we have thoroughly explored these kinds of issues, I propose responding as follows:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>“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.”<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'>- Alex.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Shawn Villaron [mailto:shawnv@microsoft.com] <br><b>Sent:</b> 22 January 2010 21:56<br><b>To:</b> SC 34 WG4<br><b>Subject:</b> Proposed Response to FPDAM Part 1 BR-0001, et al<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal>Good afternoon,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is my proposed draft response for this series of comments. Comments welcome, as always.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>shawn<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>WG4 Response<o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Rejected.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Furthermore, ISO/IEC 29500 already supports a number of different mechanisms to enable many versioning scenarios. Here is a sampling of such mechanisms:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><b>XML Namespaces –</b> Provides for “major” version increments that are not designed to be backward compatible with existing implementations. <o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><b>Extension Lists –</b> Provides for adding orthogonal data in predefined locations within the XML. See Part 1.<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><b>Parts –</b> Provides for adding entirely new payloads into the file container. See Part 2.<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><b>Alternative Content Blocks –</b> Provides for adding multiple renditions anywhere in the XML. See Part 3.<o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><b>Ignorable Namespaces –</b> Provides for adding orthogonal data anywhere in the XML. See Part 3.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span lang=EN-GB style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>______________________________________________________________________<br>This email has been scanned by the MessageLabs Email Security System.<br>For more information please visit <a href="http://www.messagelabs.com/email">http://www.messagelabs.com/email</a> <br>______________________________________________________________________<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>______________________________________________________________________<br>This email has been scanned by the MessageLabs Email Security System.<br>For more information please visit <a href="http://www.messagelabs.com/email">http://www.messagelabs.com/email</a> <br>______________________________________________________________________<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB style='font-size:12.0pt;font-family:"Times New Roman","serif"'><br>______________________________________________________________________<br>This email has been scanned by the MessageLabs Email Security System.<br>For more information please visit <a href="http://www.messagelabs.com/email">http://www.messagelabs.com/email</a> <br>______________________________________________________________________<o:p></o:p></span></p></div></body></html>