<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style>@font-face {
font-family: Wingdings;
}
@font-face {
font-family: Cambria Math;
}
@font-face {
font-family: Calibri;
}
@font-face {
font-family: Tahoma;
}
@page WordSection1 {margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
LI.MsoNormal {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
DIV.MsoNormal {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P.MsoAcetate {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: 8pt
}
LI.MsoAcetate {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: 8pt
}
DIV.MsoAcetate {
MARGIN: 0in 0in 0pt; FONT-FAMILY: "Tahoma","sans-serif"; FONT-SIZE: 8pt
}
P.MsoListParagraph {
MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
LI.MsoListParagraph {
MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
DIV.MsoListParagraph {
MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
SPAN.EmailStyle18 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: windowtext
}
SPAN.EmailStyle19 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d
}
SPAN.EmailStyle20 {
FONT-FAMILY: "Calibri","sans-serif"; COLOR: #1f497d
}
SPAN.BalloonTextChar {
FONT-FAMILY: "Tahoma","sans-serif"
}
.MsoChpDefault {
FONT-SIZE: 10pt
}
DIV.WordSection1 {
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</style>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18882">
<style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" ocsi="x">
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">Shawn,</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I think versioning is a requirement if, as Alex states, we make changes to the schemas and indeed to prose, which adds new features or alters existing behaviour within the standard.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">The problem is that it is currently not reasonably possible for someone who has implemented ECMA376-1 in an editing capacity to make their product distinguish an instance of ECMA376-1 from an instance of IS29500 transitional.
This means it will, quite reasonably open it and use code that was written for ECMA376-1 to read and update the instance. Possibly with an undesirable outcome.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">As we know from the issue with serial dates - this can cause serious problems with interoperability.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">The problem is still allowed to perpetuate along the transitional line, since there is no *required* element or attribute that reveals the version of the instance document and hence what features the document contains
and the behaviour of those features.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">On the strict line, we have a break now between ECMA376-1 and IS29500 strict, but not say, IS29500:2008 and IS29500 COR1 / AMD1 etc. When we decide to have a new version of IS29500, has there been a decision in WG4 that
I missed about the policy of changing the namespace in strict?</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">What is the trigger event for a namespace change? Major version, semantic change in element/attribute, other breaking change?</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">As regards CustomXML, this reminded me of the recent events, where we had to review our implementation in light of the patent case. We had no problems, since we did not use CustomXML, but we were considering using
it after seeing Zeyad's presentation in the Seattle WG4 meeting. From what I have read of the case and the patent itself, it seemed we would have been in an uncomfortable grey area as an implementer.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Although you say that i4i doesn't apply to the standard itself, it appears that it can certainly apply to implementations of the standard. Having a feature in a standard that invites (successful) litigation seems
to me rather unwise.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I am wondering if i4i have reviewed the relevant area of IS29500 and come up with any conclusions?
</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Maybe they are rubbing their hands together, since unless one is extremely careful, one inevitably creates an infringing implementation. I don't know, but it is still concerning.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Perhaps if a more technical explanation of the exact infringing implementation details and the changes made to remedy the infringement were available, WG4 would be able to make a more informed decision about CustomXML.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Until we decide to freeze the standard, versioning will be at least highly useful and very likely, critical.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">My apologies that I will not be on the call tonight to debate this further.</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font size="2" face="Tahoma">NOTE: I see Murata-san has weighed in with a similar point, whilst I have been finishing this mail.</font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Gareth</font></div>
<div style="DIRECTION: ltr" id="divRpF712750">
<hr tabindex="-1">
<font size="2" face="Tahoma"><b>From:</b> Shawn Villaron [shawnv@microsoft.com]<br>
<b>Sent:</b> 04 February 2010 14:15<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<br>
</font><br>
</div>
<div></div>
<div>
<div class="WordSection1">
<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.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d"></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.
</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d"></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?”</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d"></span> </p>
<div>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<p class="MsoNormal"><b><span style="FONT-FAMILY: ; FONT-SIZE: 10pt">From:</span></b><span style="FONT-FAMILY: ; FONT-SIZE: 10pt"> 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</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">Dear all,</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">This is not quite right as a response, I think.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">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.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">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.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">Of course it _<i>may</i>_ be that we conclude not to add any (more) versioning mechanisms to OOXML.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">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.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">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?</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">Until we have thoroughly explored these kinds of issues, I propose responding as follows:</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">“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 <a name="_MailEndCompose"> CH, and does not preclude further work in this area.”</a></span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB">- Alex.</span></p>
<p class="MsoNormal"><span style="COLOR: #1f497d" lang="EN-GB"></span> </p>
<div>
<div style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<p class="MsoNormal"><b><span style="FONT-FAMILY: ; FONT-SIZE: 10pt">From:</span></b><span style="FONT-FAMILY: ; FONT-SIZE: 10pt"> 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</span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"></span> </p>
<p class="MsoNormal">Good afternoon,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Here is my proposed draft response for this series of comments. Comments welcome, as always.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">shawn</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><b>WG4 Response</b></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Rejected.</p>
<p class="MsoNormal"> </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.
</p>
<p class="MsoNormal"> </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:</p>
<p class="MsoNormal"> </p>
<p style="TEXT-INDENT: -0.25in" class="MsoListParagraph"><span style="FONT-FAMILY: Symbol"><span>·<span style="LINE-HEIGHT: normal; FONT-VARIANT: normal; FONT-STYLE: normal; FONT-SIZE: 7pt; FONT-WEIGHT: normal">
</span></span></span><b>XML Namespaces –</b> Provides for “major” version increments that are not designed to be backward compatible with existing implementations.
</p>
<p style="TEXT-INDENT: -0.25in" class="MsoListParagraph"><span style="FONT-FAMILY: Symbol"><span>·<span style="LINE-HEIGHT: normal; FONT-VARIANT: normal; FONT-STYLE: normal; FONT-SIZE: 7pt; FONT-WEIGHT: normal">
</span></span></span><b>Extension Lists –</b> Provides for adding orthogonal data in predefined locations within the XML. See Part 1.</p>
<p style="TEXT-INDENT: -0.25in" class="MsoListParagraph"><span style="FONT-FAMILY: Symbol"><span>·<span style="LINE-HEIGHT: normal; FONT-VARIANT: normal; FONT-STYLE: normal; FONT-SIZE: 7pt; FONT-WEIGHT: normal">
</span></span></span><b>Parts –</b> Provides for adding entirely new payloads into the file container. See Part 2.</p>
<p style="TEXT-INDENT: -0.25in" class="MsoListParagraph"><span style="FONT-FAMILY: Symbol"><span>·<span style="LINE-HEIGHT: normal; FONT-VARIANT: normal; FONT-STYLE: normal; FONT-SIZE: 7pt; FONT-WEIGHT: normal">
</span></span></span><b>Alternative Content Blocks –</b> Provides for adding multiple renditions anywhere in the XML. See Part 3.</p>
<p style="TEXT-INDENT: -0.25in" class="MsoListParagraph"><span style="FONT-FAMILY: Symbol"><span>·<span style="LINE-HEIGHT: normal; FONT-VARIANT: normal; FONT-STYLE: normal; FONT-SIZE: 7pt; FONT-WEIGHT: normal">
</span></span></span><b>Ignorable Namespaces –</b> Provides for adding orthogonal data anywhere in the XML. See Part 3.</p>
<p class="MsoNormal"> </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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="FONT-FAMILY: ; FONT-SIZE: 12pt" lang="EN-GB"><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" target="_blank">
http://www.messagelabs.com/email</a> <br>
______________________________________________________________________</span></p>
</div>
</div>
</body>
</html>