On Wed, Jan 27, 2010 at 11:59 AM, Bruce D'Arcus <[log in to unmask]> wrote:
> On Wed, Jan 27, 2010 at 11:24 AM, Tim Williams <[log in to unmask]> wrote:
>> On Tue, Jan 26, 2010 at 3:40 PM, Per Bothner <[log in to unmask]> wrote:
>>> On 01/26/2010 12:11 PM, Ray Denenberg, Library of Congress wrote:
>>>> Well, the fundamental premise of this work is compatibility with ISO
>>>> 8601, thus any feature that is part of this dateTime spec, which is also
>>>> a feature of 8601, should be compatible with 8601. ISO 8601 uses hyphens
>>>> as separators and slash for range, so if you want to argue against them,
>>>> you'll first need to argue against the basic premise of compatibility
>>>> with ISO 8601.
>>> Most of the time following a flawed standard is better than creating a
>>> new one, I agree, as long as the flaws aren't fatal. And I'm not
>>> going to argue that using '/' for ranges is a fatal flaw - just a very
>>> annoying one, since it should have been possible to come up with a
>>> machine-readable syntax that would be (IMO) less awful for humans.
>> FWIW, I think gaining adoption is the problem. When addressing a
>> problem whose solution will never touch an end-user, as you say it's
>> best to follow even a flawed standard. In this case though, it will
>> touch the user, and so, it must be decided which is easier - to stray
>> from the flawed standard or explaining the adherence to a undesirable
>> syntax to the user. Personally, I'll stray... a "/" for a range is
>> simply unintuitive and I couldn't explain otherwise to a user that
>> doesn't know about or value the ISO standard...
> I'm not so sure I agree with the assumption that this is a user-facing
> format. As I read, this is purely for machine-reading, and it's up to
> client software to properly interpret, process (say, to sort), and
> present (in localized human-readable form) it.
> Perhaps it might be worthwhile to settle this question now?
Well, I didn't mean to muddy the waters, my own interest in lurking on
this list is to see if there are ideas that could be rolled into our
own CQL implementation for advanced date queries. This syntax is,
unfortunately, exposed directly to the users mainly because advanced
query building UI's invariably suck. So, it seems I wrongly projected
my own use-case as an assumption in this discussion... I don't suppose
anyone would buy the argument that my machines are happier with