Jesper,<div><br></div><div>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.</div><div><br></div>
<div>It's a too easy way to say: "Sorry we can't do anything, now it's too late!"</div><div><br></div><div>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"</div>
<div><br></div><div>Versionning is not about fixing existing problems as some of you suggests, it's all about fixing future potential problems</div><div><br></div><div>Mohamed<br><br><div class="gmail_quote">On Tue, Jan 26, 2010 at 8:17 AM, Jesper Lund Stocholm <span dir="ltr"><<a href="mailto:jesper.stocholm@ciber.dk">jesper.stocholm@ciber.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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>
<font color="#888888"><br>
<br>
Jesper Lund Stocholm<br>
ciber Danmark A/S<br>
</font><div class="im"><br>
> -----Original Message-----<br>
> From: Shawn Villaron [mailto:<a href="mailto:shawnv@microsoft.com">shawnv@microsoft.com</a>]<br>
</div><div class="im">> Sent: 26. januar 2010 06:19<br>
> To: MURATA Makoto (FAMILY Given)<br>
</div><div class="im">> Cc: Innovimax SARL; Rex Jaeschke; SC 34 WG4<br>
</div><div><div></div><div class="h5">> 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<br>
<br>
</div></div></blockquote></div><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 €<br>
</div>