Print

Print


On 11/08/2010 07:05 AM, Denenberg, Ray wrote:
> Well I join you in regretting that ISO chose "/". However, If we were to
> adopt a sequence of dots, or for that matter any convention other than
> "/", it would mean abandoning the premise of this work, that any feature
> prescribed, if it is a feature supported by ISO 8601, will be prescribed
> in a manner compatible with ISO 8601. My position on that is that there
> would need to be overwhelming sentiment to do that.

I agree parsimony argues for "if it is a feature supported by ISO 8601,
will be prescribed in a manner compatible with ISO 8601", but I don't
violating that rule breaks much.  To parse an EDTF specifier one needs a
EDTF-aware processor. and a 8601 processor won't cut it.  The only
thing using "/" might enable is that "converting" a 8601 string to an EDTF
would be a no-op.  However, even that would not be true, since EDTF "selects
relevant/necessary features of 8601, discarding unnecessary features."

I noted an inconsistency for "Uncertain, but known to be one of a set."
    [1667,1668, 1670-1672]
    One of the years 1667, 1668, 1670, 1671, 1672
In this context, we're using hyphens for a set.

I recommend just using ".." for an interval, so the above would be:
   [1667,1668, 1670..1672]

What about when "The endpoint of an interval is another interval"?
One option is to use parentheses - after all we already use parentheses
for grouping of questionable dates, which this is, so instead of:

   20030312/20030319//20030320/20030321
we'd use:
   (20030312..20030319)..(20030320..20030321)

Alternatively, we can use square brackets, since presumably an
"internals of intervals" really means that the endpoint is
"Uncertain, but known to be one of a set".  Thus:

   [20030312..20030319]..[20030320..20030321]

On a related note, we can possibly get rid of the "Before/after indicator".
Instead of:
   .be.1760
I think this would be more readable:
   [..1760]
If you need "before" rather than "before or equal" you could do:
   [..<1760-12-03]
instead of:
   .bf.1760-12-03

When it comes it handling 8601-style "/", we have so choices:
(1) Not allow it.  A 8601-style internal has to be explicitly
   converted before being passed to an EDTF processor.
(2) Allow, but discourage "/" as a synonym for "..".  An EDTF
processor must allow "/" in input.  On output it is recommended
(but not required) for it to produce ".." and avoid "/".
(3) Make handling of "/" optional, like in a profile.

I think (3) would causes more trouble than it is worth, so I
would recommend (1) or (2).  Specifically (1) for simplicity.
-- 
	--Per Bothner
[log in to unmask]   http://per.bothner.com/