Hi all,
I've got some time to work on this so it would be good to verify that we've
reached a conclusion :) I think we have since it's been almost a month
since anyone has posted to this thread.
It looks to me like the reduced-precision-as-range argument has pretty well
won this discussion (and I'm going to go ahead and start looking into
implementing that behavior.) But please speak up if this is really
unacceptable!
Also, has this issue been filed in JIRA?
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, Jul 19, 2012 at 1:02 PM, Martin Davis <[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
