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

Tue Jan 26 08:57:44 CET 2010

Hi Mohamed,

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.

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.

J

Jesper Lund Stocholm
ciber Danmark A/S

From: Innovimax SARL [mailto:innovimax at gmail.com] 
Sent: 26. januar 2010 08:43
To: Jesper Lund Stocholm
Cc: SC 34 WG4
Subject: Re: Proposed Response to FPDAM Part 1 BR-0001, et al

Jesper,

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.

It's a too easy way to say: "Sorry we can't do anything, now it's too late!"

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"

Versionning is not about fixing existing problems as some of you suggests, it's all about fixing future potential problems

Mohamed

On Tue, Jan 26, 2010 at 8:17 AM, Jesper Lund Stocholm <jesper.stocholm at ciber.dk> wrote:

Hi all,

I do not believe we should "water down" our statement (re: our
discussion in Paris around "respectfully disagreeing"). The reason we
are not adding a versioning mechanism is not that we are not sure about
it. The reason is that we have not seen a justifiable, /qualified/
use-case or mechanism that could not be handled by existing constructs
in IS29500.

As Rex or Shawn said, we always have the prerogative to revisit any
decision we might have made in the past - including adding a versioning
mechanism. I have a gut feeling that we might need a versioning
mechanism some time in the future, but I am not at all "unsure" that we
don't need it now.

I think the original statement should stand.

Jesper Lund Stocholm
ciber Danmark A/S

> -----Original Message-----
> From: Shawn Villaron [mailto:shawnv at microsoft.com]

> Sent: 26. januar 2010 06:19
> To: MURATA Makoto (FAMILY Given)

> Cc: Innovimax SARL; Rex Jaeschke; SC 34 WG4

> Subject: RE: Proposed Response to FPDAM Part 1 BR-0001, et al
>
> I'm increasingly confused as to how this is being interpreted as
> closing doors.  Again, here's the text, with the portion that I
believe
> keeps the door open bracketed:
>
> 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.>>
>
> In other words, we're acknowledging that evaluations are continuing
and
> that we'll make changes/additions as the evaluations dictate ...
>
> -----Original Message-----
> From: MURATA Makoto (FAMILY Given) [mailto:eb2m-mrt at asahi-net.or.jp]
> Sent: Monday, January 25, 2010 7:47 PM
> To: Shawn Villaron
> Cc: Innovimax SARL; Rex Jaeschke; SC 34 WG4
> Subject: Re: Proposed Response to FPDAM Part 1 BR-0001, et al
>
> > I'm confused.  We spent months talking about versioning in the
> context of the namespace DR.
> >So I'm confused when we say we've only talked about versioning for a
> >few hours ...
>
> Months on versioning in general, but the decision not to introduce a
> versioning attribute as part of the Part4 FPDAM1 was entirely done in
> Denmark.
>
> > I don't believe my text closes the doors on improving versioning
down
> the road.
>
> I think that it does.  Any rewrite that does not obviously close the
> doors (including  some version  attribute) is fine to me.
>
>
> Cheers,
> Makoto

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100126/3257275d/attachment-0001.htm>