I've made some clarifications to an e-mail I sent to the list yesterday,
but which didn't came to
http://listserv.loc.gov/cgi-bin/wa?A1=ind1104&L=datetime (yet). I resend
this (hopefully clarified) e-mail now.
> internal uncertain/approximate. If
> you care about it, please speak up.
There was an agreement on the need for these features and therefore, I
would really like to incorporate these features in our BNF. I consider,
though, that other things may need to be done before we can focus on
internal uncertain / approximate.
I would suggest the following plan:
1. As of today, our specification is ambiguous. On the one hand, we
exclude leap seconds in accordance with the W3C XML Schema 1.1 as
http://www.w3.org/TR/xmlschema11-2/#dt-leapsec and I consider it is OK. On
the other hand, the specification uses the term "time zone" (as the W3C
XML Schema 1.0 does), in circumstances where the W3C XML Schema 1.1 would
(as I interpret it) probably use the term "(time) zone offset" (read the
"Note" a few lines below
http://www.w3.org/TR/xmlschema11-2/#con-dateTime-day and further at
http://www.w3.org/TR/timezone/#d2e226 for details). I would like to avoid
this mixture of both versions of the W3C XML Schema in our specification.
In our specification the wording "W3C XML Schema" thus sometimes refers to
the W3C XML Schema version 1.0 and sometimes to the W3C XML Schema version
1.1 and I consider that this is the first thing we should focus on. These
two schemas are different and the readers need to know which of these our
specification refers to. I suggest to agree on one version and document
this choice in the specification. Version 1.0 *is* a recommendation and
thus stable, but it has some obvious drawbacks - it neglects the
difference between "time zone" and "(time) zone offset" for example.
Version 1.1 is (probably) better, but it is not a recommendation (yet) and
thus it may be changed, which could lead to (minor?) problems for us if we
choose it. Let's document the motivations for our choice and use the
appropriate schema consistently in our specification!
2. Thereafter, in light of the choice we made above, I would suggest to
correct the mismatches still remaining between our BNF and our
specification, for example within lists.
3. Thereafter, we could modify our specification to make it stricter (even
when it is not inconsistent), still sticking to the chosen version of the
W3C XML Schema when applicable. This would make it easier to discover
invalid values in instances.
4. (optional step) Thereafter, I would suggest to rework our specification
to make the lexical space more strict, even where the W3C XML Schemas are
not so strict. Thus, we could achieve (or at least strive towards) an
injective relation from the lexical space to the value space - at least
within the (proleptic) Gregorian calendar. Of course, both these spaces
would remain valid according to the chosen version of the W3C XML Schema
5. Now, it is time to expand the BNF to include internal uncertain /
What do you think about this plan? Comments are welcome!