Print

Print


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,