My comments on DR 10-0001

[Horton, Gareth]

Jesper,

Maybe to tighten up cell value handling in S, we could make the t attribute on cellvalue element v required and set up a comprehensive enumeration for it.

That way, the type of value in the cell would always be explicitly specified in the same place as the value itself, without all this formatting lookup business.

Currently the t attribute is used to specify that an 8601 date exists, by using a value of "d". I don't see why we can't leverage this mechanism, or some variant thereof, to help sort out potential ambiguities before we have S producers in the wild.

Gareth

-----Original Message-----
From: Jesper Lund Stocholm <jesper.stocholm at ciber.dk>
Sent: 07 April 2010 15:39
To: Jirka Kosek <jirka at kosek.cz>; Norbert Bollow <nb at bollow.ch>
Cc: e-SC34-WG4 at ecma-international.org <e-SC34-WG4 at ecma-international.org>
Subject: RE: My comments on DR 10-0001


Hi all,

> -----Original Message-----
> From: Jirka Kosek [mailto:jirka at kosek.cz]
> Sent: 1. april 2010 14:54
> To: Norbert Bollow
> Cc: e-SC34-WG4 at ecma-international.org
> Subject: Re: My comments on DR 10-0001
>
> Norbert Bollow wrote:


> > so
> > why not at that time also add text that allows, as a special
> > exception, the string "1900-02-29" for representing a value that
> > occurs in some existing (buggy) documents?
>
> Because such value is not conforming nor to ISO8601, neither to
xs:date
> datatype.

Precisely - and I am actually not aware of any tools (apart from
Microsoft Excel and OpenOffice.org Calc, of course) that handles the
leap-year bug "nicely". Even Microsoft's own .Net library pukes when it
encounters a value of "1900-02-29".

Insisting that the leap-year-bug should be allowed in documents for
conformance class Strict is in my view an attempt to "legacy-enable"
Strict - and I strongly oppose that. The rationale/idea behind S was not
to be able to make it as easy as possible for implementers to transform
documents from T to S. The idea was to get rid of the legacy heritage of
the binary document formats - yes the namespace-change itself was an
indeed attempt to make the distinction between S and T as clear as
possible - not least from an implementation point of view.

Trying to justify features in S based on the practicality of moving
documents from T to S is in my point a misunderstanding of why S was
created in the first place.

Jesper Lund Stocholm
ciber Danmark A/S