Thanks for the Draft! It seems to be a good job!

I tried to read it both with my knowledge acquired by been active on this 
list and as if I didn't know anything about it. Of course, that is quite 
impossible, but I tried it and hope that some issues that may be unclear 
for people not acquainted with EDTF appeared. I note both small typos and 
need for clarifications, along with a couple of wider suggestions.

Here, I try to formulate those both parallel readings in the order in 
which they occur in the specification:

At the beginning, the word "extenstions" seems to be misspelled.

001 - In the "feature" column, the word "date" is written with lower case 
initial, whereas the first word in this column is spelled with uppercase 
initial in all other rows of the tables.

001 - I consider that "year zero" should be clarified (maybe with an 
external link) for readers not acquainted with this concept.

002 - "Time zone" should be rewritten to "Time zone offset" for clarity. 
When changing from / to summer or winter time, we change offset without 
necessarily changing time zone, and what we mean is offset.

004 - 2004-02-01 is not "January 2" (three times)

004 - "2004-02-01/2005-02-08 [...] Month precision." Here, I assume you 
mean "day precision".

101 - "close to correct" A reader may wonder how close we mean.

102 - Here, I'm reminded of the following quotation from an e-mail:

> Thus 196u means: [...] "I hope to fill in the blanks".
This quote (although informal) could be quite illuminating for readers not 
acquainted to what we mean.

201 - The word "portion" would need to be clarified. Readers may wonder 
about constructs such as:





In other words, I consider there is a need for clarifications about nested 
parentheses and the number of digits and dashes they may contain.

202 - We could clarify the concept of "consecutive digits". What about


for example? Are these two digits to be considered consecutive? Readers 
may also wonder whether the following constructs



are allowed.

203 - A clarification is needed about constructs such as:

[1667, 1760-12]

204 - If a book is published both in 1960 and in december 1961 (according 
to what is printed in the book), is it OK to write:

{1960, 1961-12}

205 - A reader may wonder why the following is not allowed:


when we mean that an event began on an unspecified day in june 2004.

207 - I wonder about the usefulness of this feature, if the only allowed 
value also is default.

208 - At the beginning of the rightmost column, there is a space that 
should not be there: ' e' should probably be spelled 'e'

209 - The datatype of the Season Qualifier is not specified. I remember 
that we wrote it would be "xs:string", but xs:string allow (right) 
parentheses and otherwise parentheses that do not need to be paired, which 
may lead to problems when parsing. We could write "xs:string without 
parentheses". I think I would prefer the datatype xs:anyURI with the 
constrain that any right parenthesis would be escaped as '%29' (as usual 
in such contexts). Using anyURI would ease language independent 
comparisons. We could qualify a season such as:


We could also suggest a number of adequate URIs, making clear that users 
may use any URIs they wish.