DR 11-0021 ? WML: Support for DrawingML inadequately specified

[Chris Rae]

This is true for adding features, but not for fixing "bugs" where the older version expected different behaviour. The DrawingML problem is an interesting one - older versions of software aren't expecting it to be "fixed", of course, but I think it's obviously an omission in the standard and it forces any new Transitional implementations to implement VML , which they may not wish to do.

Chris

-----Original Message-----
From: Alex Brown [mailto:alexb at griffinbrown.co.uk] 
Sent: 10 June 2011 11:38
To: Chris Rae; MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma-international.org
Subject: RE: DR 11-0021 ? WML: Support for DrawingML inadequately specified

Chris hi

I can understand the need for convertibility, but surely no applications currently exist that know about future variations of T that we might invent.

So we would actually being doing a dis-service to users who have "older versions of software" by mucking around with the file format (T) that they use, wouldn't we?

- Alex.



> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: 10 June 2011 18:23
> To: Alex Brown; MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma- 
> international.org
> Subject: RE: DR 11-0021 ? WML: Support for DrawingML inadequately 
> specified
> 
> We have to accept that the corpus of legacy documents is going to 
> expand at the moment, chiefly because it has to track the corpus of legacy applications.
> With any "new" document format, there's the perennial problem of how 
> one shares that document with users who have an older version of 
> software (or an unknown version of software). The most obvious case is 
> users in different organisations, but perhaps the more critical one is 
> users in the same organisation with a staged software rollout - most 
> corporate customers will take a year or two to steadily roll out new 
> software or IT policies, and a part of that plan always requires some 
> sort of easy migration between users who have been upgraded and users who haven't.
> 
> For a file format to succeed, implementers need to provide a good 
> story for both forward and backward conversion. I would much prefer 
> that this is done by "carrot" (adding new features to the new format) 
> rather than stick (not fixing errors or omissions in the old format).
> 
> This seems like a good topic for discussion in person - I just wanted 
> to answer Alex's question about the scenario I'm concerned about.
> 
> Chris
> 
> -----Original Message-----
> From: Alex Brown [mailto:alexb at griffinbrown.co.uk]
> Sent: 10 June 2011 07:13
> To: Chris Rae; MURATA Makoto (FAMILY Given); e-SC34-WG4 at ecma- 
> international.org
> Subject: RE: DR 11-0021 ? WML: Support for DrawingML inadequately 
> specified
> 
> Dear Chris, all,
> 
> > As an implementer I would much prefer that these changes were also 
> > adopted in Part 4, as otherwise we are going to experience data loss 
> > when converting Strict documents to Transitional ones
> 
> Since when has T been a conversion target for S documents? Isn't the 
> scope of T that it represents the existing corpus of legacy documents? 
> that being the case - we shouldn't be extending the format  should we?
> 
> I can't imagine any scenario where this kind of conversion would be helpful:
> what am I missing?
> 
> - Alex.
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __________________________________________________________
> ____________
> 
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __________________________________________________________
> ____________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________