[SPAM] DR 08-0012 Discussion document for tele conference on Thursday about namespace change

[Horton, Gareth]

Hi Jesper,

 

Not a very pleasant prospect.  I can see the reasoning, but not something that would be acceptable in a product release in my house, so to speak.

 

Obviously the strict namespace does need to change.  For data integrity purposes, I think there is also a very good case for the transitional namespace to change.

 

The issue I am focused on is the date issue, as you already know.

 

In a previous document, N1194 you mention the impacts:

 

"Attempting to open an ISO/IEC 29500 transitional document in an application that only understands ECMA 376 1st Ed. will depend on whether the transitional document uses any of the new

syntax (e.g. ISO 8601 dates, comments in spreadsheets, bitmasks or object embedding) added at the BRM.

o If the transitional document uses the new syntax, behaviour will be application defined. ISO 8601 dates will be corrupted in MS Office and OpenOffice.org as described above (an application

bug). Most documents will most likely be opened with no errors."

 

The problem is that anyone implementing transitional would certainly implement ISO 8601 dates in spreadsheets, going from the intent of the spec, which uses an ISO 8601 date as an example.  The fact that there is now an attribute to indicate ISO8601 dates does not really help 'legacy' apps.  

 

In 18.17.4.1 - "All date values stored in cells within a SpreadsheetML file are stored in the ISO 8601 format."

 

Would you implement writing a serial date by default going off the spec? No.  We can assume that going forward, all dates in transitional and strict files will be ISO 8601. Maybe some apps will roundtrip the existing data, so there won't be an acceleration of existing documents being silently updated, but we can assume all new instances will write ISO 8601.

 

I contend that a reasonable proportion of spreadsheets contain dates. Most reporting and analysis has a date element - even if that is just shown as a month, quarter etc using a formatting mask.  It will still be a date.  I also disagree that the problem lies with the apps - they are working absolutely to the spec as it was designed at the time - the semantic meaning of the string element involved was a serial date number.  The change made at the BRM was not well thought out.  One could say that the spec caused the problem, it is it's duty to solve it.  This approach leaves it utterly on the shoulders of implementers (and indeed users - via updates/patch management) to fix it.

 

Of course, all this would be moot if there was a mechanism to determine versions of documents instances back in ECMA376-1, but there wasn't.  As I might have mentioned before, Office 2007 implemented the change in specs with a namespace change during the beta, so we, as probably others, reasonably assumed that the lack of any other versioning strategy implied a namespace change would be the future mechanism.

 

If we don't change the transitional namespace, then there will be a big education job with customers and implementers to ensure that they retrofit existing apps to safely consume the "ISO" version of Open XML files.  That will not give either of these parties a good feeling. "Don't use anything that produces ISO Open XML until all your software is patched" does not have a good ring to it.

 

On the other hand, I have not heard the all the detailed arguments for keeping the transitional namespace, so I'll reserve judgement until then, as I have not had a lot of time to consider the other side.

 

A point regarding the proposal adding the new conformance attributes - what is the reason for not using a version number now? 

 

Gareth

 

 

From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: 29 April 2009 11:05
To: e-sc34-wg4 at ecma-international.org
Subject: [SPAM] DR 08-0012 Discussion document for tele conference on Thursday about namespace change

 

Hello all,

 

Shawn and I have been busy working on investigating the impact of changing the namespace and the required changes to the specification. We have made a draft discussion document (attached to this email) and we will use this to start the discussion tomorrow. The document contains our draft response to DR 08-0012 and what we intend to do. Shawn and I will have more detailed information for you tomorrow during the teleconference.

 

Jesper Lund Stocholm
 
Lautruphøj 1-3
DK-2750 Ballerup
Denmark

Tlf.: +45 30 94 55 70
Email: jesper.stocholm at ciber.dk <mailto:jesper.stocholm at ciber.dk> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090429/0589c573/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2609 bytes
Desc: image001.gif
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20090429/0589c573/attachment.gif>