My comments on DR 10-0001

[Doug Mahugh]

Jesper,

Chris is on vacation this week, but I believe we have a workable solution to this that addresses your concerns.  Chris will respond in more detail next week.

Regards,
Doug

-----Original Message-----
From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: Wednesday, March 31, 2010 5:37 AM
To: Chris Rae; SC 34 WG4
Subject: RE: My comments on DR 10-0001

Hi Chris (and all),

Let me address some of the points you make.

First, let me emphasize a few things:

1. There is no such thing as a serial date in Part 1. I know that some interprets the last paragraph in Part 1, section 18.17.4 as allowing serial dates, but this paragraph (in my reading) deals exclusively with guidance to strict consumers on how to interpret non-conforming spreadsheets with serial dates.

2. Dates are persisted in strict documents (spreadsheets) as ISO-dates.
Not as serial dates but as ISO-dates! This effectively means that the leap-year bug does not exist in S documents, since the date 1900-02-29 cannot be persisted in ISO-8601 format.

See below:

> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: 26. marts 2010 17:20
> To: 'SC 34 WG4'
> Subject: My comments on DR 10-0001
> 
> DR 10-0001: SML: Remove dateCompatibility attribute from strict
schemas
> and occurring places in Part 1
> 
> I am not in favour of this DR because of the difficulty it presents in 
> migrating documents from transitional to strict.

Yes, we are aware of those difficulties.

> Because dates are
> treated as numbers at runtime by spreadsheet applications, it's 
> impossible to tell whether a given cell truly contains a date.

No - in strict documents dates are not serial dates - they are persisted in ISO-8601 format. There is no issue wrt figuring out if the cell contains a date or not. The only time this would pose a difficulty would be if someone created an strict spreadsheet with a serial date in it and styling it using "the old transitional way". But that document would be non-conforming since it would be in violation with the constraint that

"Each unique instant in SpreadsheetML time is stored as an ISO 8601-formatted string"

> All one
> can tell is whether a cell is *formatted* as a date. If I type
=TODAY()
> into a cell, for example, and then format it as a number, I will see 
> "40263". Passing this value into date-related functions will produce 
> valid values and reformatting the cell as a date format will show a 
> date - as far as I (as the user) am concerned, the cell contains a 
> date, but my app has no way to know that.

Yes - for transitional files.

> Removing the leap year bug from a workbook will cause any values
before
> 1st March 1900 to display differently - they will all move forward by 
> one day. Additionally, several functions (DAY, MONTH, etc) will
produce
> different results. Any existing spreadsheet hand-crafted to "fix" the 
> leap year bug will now start to produce incorrect results.

I dissagree. Dates in S files would not suddenly "move" - since they would not be serial dates - they would be ISO-dates. They wouldn't even move in existing transitional documents, because the attribute should clearly stay in T and it has a default value of "true". The only case this would be a problem would be when an application is trying to convert a spreadsheet from S to T. If a vendor is not comfortable in being able to convert a T spreadsheet to S, they should not do it. 

> I acknowledge that this is a small date range, but the impossibility
of
> mitigating risk to users' data will make it difficult for implementers 
> to safely transition existing documents to strict, and as such I
oppose
> this DR.

This has not much to do with whether the date range is small or not.



// This has to do with an issue that in the opinion of Denmark is a clear legacy-issue and which should stay that way. //



I realize that not being able to (re)use the leap year bug in S files will make it impossible to convert certain documents, but that is really a vendor issue. I also realize that vendors (exclusively) supporting the leap-year-bug in their calculation engines will have to make
(substantial) modifications to it, but again - this is a vendor issue and not a specification-issue.

The presence of the dateCompatibility attribute in S documents is in my mind a clear self-contradiction in OOXML, because requiring saving dates in ISO-8601 format clearly removes the leap-year-bug from S files (sine the date 1900-02-29 cannot be saved in S spreadsheets). Having an attribute requiring a consumer to somehow re-apply the leap-year-bug based on a persistence format not supporting it really makes it virtually impossible to implement OOXML S.


Jesper Lund Stocholm
ciber Danmark A/S