My comments on DR 10-0001

[Horton, Gareth]

Jesper,

As the spec is currently written, you must deduce date values in S, as you have to persist them in the cell value as ISO8601 dates with the t attribute set to d.

That's why my point is under what possible circumstances can the prohibition of writing 29th Feb 1900 be catastrophic in a conversion.

I think conversion from T to S is extremely important, given my experience in spreadsheets.  A huge amount of spreadsheets were created years ago and new sheets, ranges, data is replaced, added and removed in those spreadsheets over periods of years.

Such documents have historically survived and evolved to take advantage of new features in applications, do you propose that we should seek to put a stop to this and put them in a Transitional stasis, rather than allowing them to take advantage of new features in an evolving standard?

Gareth

-----Original Message-----
From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: 08 April 2010 14:07
To: Horton, Gareth; Norbert Bollow; e-sc34-wg4 at ecma-international.org
Subject: RE: My comments on DR 10-0001

Hi Gareth (all),

> -----Original Message-----
> From: Horton, Gareth [mailto:Gareth_Horton at datawatch.com]
> Sent: 8. april 2010 14:19
> To: Norbert Bollow; e-sc34-wg4 at ecma-international.org
> Subject: RE: My comments on DR 10-0001
> 
> Hi all,
> 
> The issue is probably moot in transitional, as there is an amendment
> planned to remove ISO8601 date string representations of dates from
> spreadsheet cell values to avoid catastrophic data loss issues for
> existing applications.

+1 (yes)

> I agree with Norbert that invalid dates with respect to a defined
> subset of ISO8601 should not be persisted in the SML cell value of
> Strict documents.

+1

> Unless someone can come up with a compelling real world scenario of a
> Transitional document where the existence of the 29th February 1900 is
> critical to it's validity and continued operation when converted to a
> Strict document, I see no reason for it's inclusion in Strict.  I am
> not considering simple serial value offset issues, as they can be
> easily resolved during the conversion.

I don't think this is the right way to put it. It would be relatively easy to make a spreadsheet that would be almost impossible to /programmatically/ deduce date values for (think of a serial value formatted with a custom numFmt (number format). I certainly would not like to be the one responsible for writing that parser.

I am more interesting in a "compelling real world scenario" where a T spreadsheet MUST be transformed to S unless babies are killed. The only reason I see (off the top of my head) for insisting that all T spreadsheets MUST be (easily) convertible to S is procurement - but isn't that really out of scope for WG4?

I am looking forward to our discussion in about an hour's time.

:o)

Jesper Lund Stocholm
ciber Danmark A/S