On Fri, 17 Oct 1997, John A. Kunze wrote:
> > Date: Fri, 17 Oct 1997 13:55:43 +0100
> > From: Paul Miller <[log in to unmask]>
> >
> > Simon Cox wrote:
> > > My understanding was that a syntax for indicating spans
> > > (disjoint or not) within a single (sub-)element is
> > > intended, rather than using repeating (sub-)elements
> > > min/max etc - ie the contents of a single DC.Date might
> > > include several date/times linked with suitable operators
> > > (eg "-" , "," , "..." etc) - this would be comparable with
> > > the proposed DC.Coverage.Polygon which has multiple
> > > vertices.
> >
> > Yes, I understood that to be the current wish of the date group, too. I
> > understood it, though, as their current RECOMMENDATION within an ongoing
> > debate, rather than a final decision.
> Yes, I believe Dirk's explanation and Paul's reminder that this
> was a recommendation accurately reflect the thinking at DC-5.
> It's clear that it makes sense now to try to harmonize
> the Date recommendation with the work of the Coverage group.
Yes, althouhg I would like to stress that the actual expression
methods are still very much in the air IMHO, and perhaps not even
near a level where a consensus backed recomondation could be made.
> I'd summarize the harmonization issues as follows:
>
> Separate start and end elements (t.min, t.max) have the distinct
> advantage that components are broken out in advance, simplifying
> the date syntax. It's less compact and not optimal for human viewing,
> but parsers will recognize the end points instantly.
> An integrated range (ie, in one element) complicates the syntax (if it can
> be accommodated at all in the 8601 profile), but gets around the problem
> of matching range endpoints; separate end point elements will likely
> require new syntax rules to prevent confusion around repeating ranges.
Althouhg it complicates the syntax; I would challenge that it complicates
implementations.. from limited experience in the geo/spatial arena, where
both formats are in use, I would conclude that keeping meaningfull
information blobs closely grouped in one element is worth it and simpliefs
the code considrably.
> Other considerations: Creating an integrated range syntax will be an
> important step in choosing between the above two approaches. According
> to Simon, the Coverage.Polygon already has a syntax that accommodates
> multiple end points, so maybe that's a place to start.
>From an implementors perspective (all I have :-) I would like to stress
that the priciple of esuring that each element is meaningfull in its own
right, (ie. Date: 12-10-1997 .. 17-10-1997 versus the two line
Date.1: 12-10-1997\nDate.2: 17-10.1997) has IMHO serious advantages and
makes the implementors live a lot easier.
However I would be very much against going one stap further and NOT
to be using the repeatability when expressing dates, so an event which
happens on two days, 10 and 17 of october should be expressed as
Date: 10 October 1997
Date: 17 October 1997
rather than
Date: 10 October 1997, 17 October 1997
Assuimg that each date is valid information witout the other date.
Dw.
|