Hello!
Here are some clarifications.
[1] Centuries
> the intent is that the term "century"
> be undefined, but that, still, '00'
> means " The interval beginning with
> year 0000 and ending with year 0099".
According to the century note, such a period is noted in another way:
"for 1900 to 1999 use 1900-01-01/P100Y."
Consistently, I would expect that the
> interval beginning with year 0000 and
> ending with year 0099
would be written
0000-01-01/P100Y
which is longer, but much more obviously shows what it means.
The following question will be:
How should we write down a century when the source does not clarify
exactly which years are meant? AFAIR, this was a use case. If we do not
use a two digit number for that, we should formulate an alternative. One
possibility would be to base it on our existing vocabulary, such as
writing "the first century" as:
0000-07-02~/P100Y
This would meant the 100-year period begining approximately on the second
of july of year 0000. I choose the second of july because it is at the
middle of the year. One another (better) alternative would be to decide to
write (for example):
c00
for the first (undefined) century.
[2] Question marks
> > If there is a semantic difference between
> > 2011?
> > on the one hand and
> > (2011)?
> No.
Then, I would like to avoid one of these notations (which is easy to fix).
> > or between
> > 2011?-04
> > on the one hand and
> > (2011)?-04
> The first is not intended to be valid.
I think that the BNF would be more consistent and easier to write if we
consider the SECOND as non-valid. My suggestion is not counter-intuitive
at all: If a question mark comes directly after a year, it is quite
obvious that the question mark refers to the year and I consider we do not
need parentheses for that.
> > > uncertOrApprox = date ("?" | "~")
> > uncertOrApprox = ( dateAndTime | longYear | yearMonth | yearMonthDay ) ( "~" | "?" ) ( qualifier )?
> > This would allow for uncertain or
> > approximate long years and also avoid
> > constructs like
> > 2011?? (* with double question marks *)
> But the date definition already includes
> yearMonth and yearMonthDay (as well as
> some other things that yours doesn't).
My aim was precisely to exclude (a lonely) "year" here, and thus to avoid
double question marks and other redundant syntax.
> I cannot see how the double question mark can be constructed.
According to the BNF, we have:
uncertOrApprox = (date | dateAndTime | longYear) ("?" | "~")
which allows an uncertOrApprox as
date "?"
According to the BNF, date is
date = positiveDate | negativeDate
which allows an uncertOrApprox as
positiveDate "?"
According to the BNF, positiveDate is
positiveDate = century | year | yearMonth | yearMonthDay
which allows an uncertOrApprox as
year "?"
According to the BNF, year is
year = baseYear | "("baseYear")" ("?" | "~")
which allows an uncertOrApprox as
"(" baseYear ")" "?" "?"
According to the BNF, baseYear is
baseYear = digit digit digit digit
which allows an uncertOrApprox as
"(" digit digit digit digit ")" "?" "?"
which obviously allows dates such as
(2011)??
with two question marks. This may be easily avoided as I showed in my
previous e-mail.
[3] Lists
> inclusiveList = "{" listContent "}"
> choiceList = "[" listContent "]"
> listContent = earlier | (earlier ",")? listElement ("," listElement)* | (earlier ",")? (listElement",")+ (later) | (earlier ",")? (later)
> listElement = date | consecutives
> I think that handles everything.
This "listContent" could be simplified as:
listContent = earlier | (earlier ",")? listElement ("," listElement)* | (earlier ",")? (listElement",")* (later)
But none of them solves the problem of avoiding lists such as:
[2011]
which as I previously explained could be avoided. Avoiding them would be
welcome.
I plan to re-read the whole BNF within a couple of days.
Regards!
SaaĊĦha,
|