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

[Jesper Lund Stocholm]

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