A few more pokes at the moribund nag below... (although I would suggest
that it's actually far from expiring, and we still need to figure out how
to corral this cayuse!)
On Wed, Jul 18, 2012 at 5:04 PM, Ian Schneider <[email protected]>wrote:
> Martin,
>
> Thanks for all your thoughts in this matter. I'm not trying to be a
> stubborn thorn in the side of reason, more a devil's advocate. So,
> acknowledging the risk of beating this near dead horse further...
>
It's good to have lots of eyes on this issue - it's quick tricky (as
temporal processing always is...)
>
> On Tue, Jul 17, 2012 at 10:45 AM, Andrea Aime
> <[email protected]> wrote:
> > On Tue, Jul 17, 2012 at 6:18 PM, Martin Davis <[email protected]>
> wrote:
> >>
> >> Two more thoughts in favour of "reduced precision = interval":
> >>
> >> 1. Expressiveness - If reduced-precision time strings are taken to mean
> a
> >> precise instant, then there is no simple way of expressing a standard
> >> interval. Whereas if reduced-precision is interpreted as an interval,
> it's
> >> still possible to express an instant via a full-precision string.
>
> Agreed. My counterpoint would be that by being explicit, both are
> supported.
I don't see how the "reduced-precision-as-instant" approach supports
expressing intervals in a convenient way. Wouldn't it mean that expressing
a range for a single calendar year requires the range
"2011/2011-12-31T11:59:59.999Z"? That seems pretty onerous and unreadable.
Potentially inaccurate too, due to the truncation at 3 decimal places.
What if a dataset allowed more precision for time and contained a value at
2011-12-1312:59:59.999999 ?
> Since software is going to be making the request, the
> 'expressiveness' argument seems less convincing - the client can
> support being expressive whilst still adhering to the protocol. While
> making manual WMS requests is a nice option when debugging, how many
> folks beyond developers are manually editing WMS parameters to achieve
> success in their endeavors?
I agree that automated clients have different requirements for "ease of
use" than human ones, and they are probably of primary importance.
However, DWB provides a nice counterexample! Also, I think the real issue
is what is the correct interpretation of the standard. (And it may well be
that the standard doesn't actually provide the most ideal protocol for
automated use - wouldn't be the first time this has happened).
> To address the concern about February
> being a leap month, most clients would have access to calendar math
> and could formulate the appropriate request.
>
>
> >> 2. Common Usage: When someone says "2012" they typically mean the entire
> >> year 2012, not the instant at the start of the year. Likewise for
> other
> >> reduced-precision expressions of time. (I realize that standards often
> >> don't let reality intrude, but it might be taken into consideration in
> >> absence of other clear direction)
>
> Totally and completely agree. The problem as I see it is that to
> achieve both 'Common Usage' _and_ adhere to the spec, we introduce a
> difference in behavior - if 2012 means all of 2012 excluding
> 2013-01-01T00:00:00Z but 2012/2013 means _including_ that first day of
> the new year (as per the spec), then this would bad™.
My interpretation is that 2012/2013 means "all of both 2012 and 2013". To
express just "the year 2012" it would be either "2012" or "2012/2012".
Agreed the latter range looks funny to human eyes, but it might be simpler
for an automated client to generate.
> I again submit
> the evidence that in many domains, single increments on a precision
> element (e.g. 1 year, 1 month, etc.) are _not_ standard or common
> usage (think census data, seasonal weather deviations from norm,
> stream gauge-data, weather forecasts, etc.).
>
Yes, agreed. And in that case the fully-specified time range format will
be required. This is not prevented by the "reduced-precision-as-interval"
interpretation. And as you point out this should not be a problem for
automated clients to generate.
My take on the standard is that it's just trying to allow a more flexible
usage pattern where it can be useful and does not impact correctness and
consistency. But it can't provide a shorthand for every possible temporal
use case.
>
> --
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
