My comments on DR 10-0001

[Rick Jelliffe]

Jesper Lund Stocholm wrote:
> It'd be interesting to hear more details on this, if you have it.
>   
Background:

  * IS8601 has a variety of syntaxes for kinds of Gregorian dates. The 
2004 version is at http://dotat.at/tmp/ISO_8601-2004_E.pdf

  * XSD datatypes has a variety of datatypes for kinds of dates, 
specifically xs:date. This is based on a subset of IS8601 syntax with 
specific value-space extensions to handle pre-Gregorian dates. See 
http://www.w3.org/TR/xmlschema-2/#deviantformats

  * It is the custom of some spreadsheet programs, it seems, to allow 
what I call "ordinal dates", where the day number is an index from the 
start of the month, rather than a "cardinal date"--a member of a limited 
set of the days available for that month. (Do I have miy terms correct?) 
This may have some calculation benefits and a certain conceptual appeal, 
but it still needs to be justified better for it to be acceptable for 
the forwards-looking standard.

 * The main thing that these ordinal dates have against them is that 
normal date processing software does not cope with them. Other problems 
are that relative dates go beyond the semantics in XSD Datatypes, 
further compexifies the standard and its implementation, and  alarm the 
horses.

HTML5:

HTML5 is a controversial effort from the WHATWG (a vendors-dominated 
group) and the W3C: this partnership has much strain, mostly because the 
W3C is keen on aspirational upgrades to HTML while WHATWG's criticized 
editor is keen on the standard reflecting reality. This situation is not 
entirely unknown at other bodies.

HTML5 has "conforming features", "obsolete but conforming features" and 
"non-conforming features". It defines a "conforming document" and a 
"conformance checker".  An application is not required to be a 
conformance checker or fail on non-conformance. See 
http://www.whatwg.org/specs/web-apps/current-work/

Most interesting, HTML5 defines several actions to take in the event of 
an error occurring. In the case of HTML5, these are given in 
non-normative text: this is a rather confused idea of what non-normative 
means IHMO since words such as MAY and SHOULD can cover it better. But 
obviously they want to avoid any idea that the documents with these 
errors conform, while at the same time encouraging browsers to render 
them in a certain way.  (So HTML5 has a generic SGML/XML-y parser, which 
builds the 'DTD ' into the parser rather than being generic.)

Problems with overlapping inline formatting ranges are handled in the 
following novel way, see 
http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#adoptionAgency
 * Some cause a "parse error" which is ignored for parsing
 * Some cause a "parse error" which gets rectified by manipulating the 
stack of open elements
In otherwords, the emphasis is on recovery.

OOXML:

I suggest that the same approach might be applicable for OOXML dates, if 
I have understood the issue from the emails.

For example, this kind of text:

"Date Error Correction in spreadsheets: (Normative)

A conforming producer application must generate valid dates. A 
conforming document must contain valid dates. A conforming consumer 
application may provide the following limited date correction:  if the 
day value is larger than the maximum number of days possible in that 
month and year, treat the day as if it were an index of days from the 
start of the given month. A consuming application with a user agent must 
not indicate to the user that a document with this datatype invalidity 
is valid or conforming.  A conformance test suite for this standard must 
not represent any test for this error correction as contributing to, or 
being indicative of, application conformance.

NOTE: (Informative) Other forms of automatic data correction are 
non-conforming in principle, to allow interoperability and reduce 
special cases. A consumer application may provide such features, but a 
user agent must not indicate to the user that this is conforming 
behaviour."



Cheers
Rick jelliffe