<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=utf-8"><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:12.0pt;
font-family:"Times New Roman","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";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:85.05pt 56.7pt 85.05pt 56.7pt;}
div.WordSection1
{page:WordSection1;}
--></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='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>On a similar note, Mohamed, did you want to add a versioning attribute ( or other technology ) now in response to the BR-0001 set of comments? I thought in my notes we agreed to reject this, and by implication, not add a versioning attribute at the moment. Bu reading your note I wonder if my notes are in error?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";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"'> Jesper Lund Stocholm [mailto:jesper.stocholm@ciber.dk] <br><b>Sent:</b> Monday, January 25, 2010 11:58 PM<br><b>Cc:</b> SC 34 WG4<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 style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Mohamed,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Well, in terms of ”breaking stuff” I think we have already moved past the point of being able to make an non-intrusive/non-breaking addition of a versioning mechanism. Should we at some point decide to add one, I cannot see how the future problems should be any greater than the problems we face should we add one today.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I can promise you, that should we in a few months start working on a versioning mechanism, I would not accept a “sorry, too late …”-argument to avoid adding it – should we find a reason for it.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Jesper Lund Stocholm<br></span></b><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#363434'>c</span></b><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:purple'>i</span></b><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#363434'>ber</span></b><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:gray'> Danmark A/S</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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"'> Innovimax SARL [mailto:innovimax@gmail.com] <br><b>Sent:</b> 26. januar 2010 08:43<br><b>To:</b> Jesper Lund Stocholm<br><b>Cc:</b> SC 34 WG4<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=DA><o:p> </o:p></span></p><p class=MsoNormal><span lang=DA>Jesper,<o:p></o:p></span></p><div><p class=MsoNormal><span lang=DA><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=DA>The problem with versionning is that, it might be too late in the future, and the argument that we don't "have a time travel machine" is still sticking in my throat.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=DA>It's a too easy way to say: "Sorry we can't do anything, now it's too late!"<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=DA>That's why saying that we are "unsure" is the least we could say since probably in few months when we will seriously consider adding some more precise mechanism, some or all will answer "sorry, too late, we don't have a time travel machine"<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=DA>Versionning is not about fixing existing problems as some of you suggests, it's all about fixing future potential problems<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA><o:p> </o:p></span></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=DA>Mohamed<o:p></o:p></span></p><div><p class=MsoNormal><span lang=DA>On Tue, Jan 26, 2010 at 8:17 AM, Jesper Lund Stocholm <<a href="mailto:jesper.stocholm@ciber.dk">jesper.stocholm@ciber.dk</a>> wrote:<o:p></o:p></span></p><p class=MsoNormal><span lang=DA>Hi all,<br><br>I do not believe we should "water down" our statement (re: our<br>discussion in Paris around "respectfully disagreeing"). The reason we<br>are not adding a versioning mechanism is not that we are not sure about<br>it. The reason is that we have not seen a justifiable, /qualified/<br>use-case or mechanism that could not be handled by existing constructs<br>in IS29500.<br><br>As Rex or Shawn said, we always have the prerogative to revisit any<br>decision we might have made in the past - including adding a versioning<br>mechanism. I have a gut feeling that we might need a versioning<br>mechanism some time in the future, but I am not at all "unsure" that we<br>don't need it now.<br><br>I think the original statement should stand.<br><span style='color:#888888'><br><br>Jesper Lund Stocholm<br>ciber Danmark A/S</span><o:p></o:p></span></p><div><p class=MsoNormal><span lang=DA><br>> -----Original Message-----<br>> From: Shawn Villaron [mailto:<a href="mailto:shawnv@microsoft.com">shawnv@microsoft.com</a>]<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA>> Sent: 26. januar 2010 06:19<br>> To: MURATA Makoto (FAMILY Given)<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=DA>> Cc: Innovimax SARL; Rex Jaeschke; SC 34 WG4<o:p></o:p></span></p></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><span lang=DA>> Subject: RE: Proposed Response to FPDAM Part 1 BR-0001, et al<br>><br>> I'm increasingly confused as to how this is being interpreted as<br>> closing doors. Again, here's the text, with the portion that I<br>believe<br>> keeps the door open bracketed:<br>><br>> WG4 Response<br>><br>> Rejected.<br>><br>> WG4 has conducted extensive research into versioning technology<br>> associated with ISO/IEC 29500. Our conclusions are that, absent a<br>> clearly specified, unsupported versioning use case, additional<br>> versioning technology should not be added to ISO/IEC 29500. The<br>> potential consequences of introducing a flawed versioning technology<br>> clearly outweigh any potential benefits.<br>><br>> Furthermore, ISO/IEC 29500 already supports a number of different<br>> mechanisms to enable many versioning scenarios. Here is a sampling of<br>> such mechanisms:<br>><br>> * XML Namespaces - Provides for "major" version increments<br>> that are not designed to be backward compatible with existing<br>> implementations.<br>> * Extension Lists - Provides for adding orthogonal data in<br>> predefined locations within the XML. See Part 1.<br>> * Parts - Provides for adding entirely new payloads into the<br>> file container. See Part 2.<br>> * Alternative Content Blocks - Provides for adding multiple<br>> renditions anywhere in the XML. See Part 3.<br>> * Ignorable Namespaces - Provides for adding orthogonal data<br>> anywhere in the XML. See Part 3.<br>><br>> Given these, and other, mechanisms currently provided for in ISO/IEC<br>> 29500, and that such mechanisms provide support for the known<br>> versioning use cases, WG4 does not believe we need a new versioning<br>> technology. <<We continue to evaluate new versioning-related use<br>> cases, and in the event we find one which cannot be supported by<br>> existing versioning technologies, we will consider adding additional<br>> versioning technology at that time.>><br>><br>> In other words, we're acknowledging that evaluations are continuing<br>and<br>> that we'll make changes/additions as the evaluations dictate ...<br>><br>> -----Original Message-----<br>> From: MURATA Makoto (FAMILY Given) [mailto:<a href="mailto:eb2m-mrt@asahi-net.or.jp">eb2m-mrt@asahi-net.or.jp</a>]<br>> Sent: Monday, January 25, 2010 7:47 PM<br>> To: Shawn Villaron<br>> Cc: Innovimax SARL; Rex Jaeschke; SC 34 WG4<br>> Subject: Re: Proposed Response to FPDAM Part 1 BR-0001, et al<br>><br>> > I'm confused. We spent months talking about versioning in the<br>> context of the namespace DR.<br>> >So I'm confused when we say we've only talked about versioning for a<br>> >few hours ...<br>><br>> Months on versioning in general, but the decision not to introduce a<br>> versioning attribute as part of the Part4 FPDAM1 was entirely done in<br>> Denmark.<br>><br>> > I don't believe my text closes the doors on improving versioning<br>down<br>> the road.<br>><br>> I think that it does. Any rewrite that does not obviously close the<br>> doors (including some version attribute) is fine to me.<br>><br>><br>> Cheers,<br>> Makoto<o:p></o:p></span></p></div></div></div><p class=MsoNormal><span lang=DA><br><br clear=all><br>-- <br>Innovimax SARL<br>Consulting, Training & XML Development<br>9, impasse des Orteaux<br>75020 Paris<br>Tel : +33 9 52 475787<br>Fax : +33 1 4356 1746<br><a href="http://www.innovimax.fr">http://www.innovimax.fr</a><br>RCS Paris 488.018.631<br>SARL au capital de 10.000 €<o:p></o:p></span></p></div></div></div></body></html>