On Mon, 24 Jan 2011 09:09:34 -0500, Denenberg, Ray wrote
> Michael said:
> 'Most obviously, in most data interchange applications, it's usually
> regarded as preferable to eliminate as much variation as possible in
> formats: if there is no difference in meaning between "2011-01-21"
> and "20110121", people interested solely in the exchange of data
> among databases will (again, in my experience) unanimously prefer to
> choose one of these formats and require it, rather than allowing
> either. That seems good practice to me.'

As Ray points out there are business cases for one over the other. I
personally think the dash format is the superior as its less prone to
programmer error and easier for some systems to parse.
As a programmer I do not care. Both are easy enough for me to create, detect
and parse...

> Back to "user input". I wish to highlight the distinction between
> "format for user input" and "human readable format". I believe we
> are NOT developing a format for user input, and that we ARE
> developing a human readable format - with the following caveat:

A human readable + easily human writable (e.g. trivial for people to
covert in their heads from other date-times based on the International
calendar) = suitable for user input

> "'human readable' is in the eyes of the human." And along with
> "human readable" goes "human typeable".

Correct. What else could anyone want?

>
> Bear with me, or skip the following two paragraphs if you like.
>
> I have spent a number of years working on the CQL query language.
> http://www.loc.gov/standards/sru/specs/cql.html. Debate has raged
> among CQL developers and implementers whether it is intended as a
> human readable language. And the answer (my answer, anyway) is that
> it is intended to support very simple to very complex queries, and
> the level of complexity of a given query string is comensurate with
> the complexity of the query. So simple queries, like "cat and dog"
> are human readable/typeable. But there are complex queries
> supported that someone well versed in CQL might be able to read but
> most users would not, and nobody would want to type them.

CQL (of which I am NOT a fan but accept) was designed upon the basis
of a European Union user query format.

>
> A number of years ago, an information retrieval scientist suggested
> that there be a committee to develop a "user input" standard for

But lets recall the argument for CQL back then.. an enhanced user format
that would be suitable for computer to computer....
 
> CQL. It would be an adjunct to the CQL standard, not part of the
> standard itself: a format for user input that would make it easy for
> a user to create complex queries without knowing the actual CQL

That is a question of user interface. CQL is CQL is CQL just as the
Isearch query language is still alive and well as a user query syntax
for advanced queries by among other the USPTO (and in a super-enriched
form in our own deployed systems).. Let us recall that the computer´to
computer "query" standard was not these "languages" but, simply put,
binary encoded within ISO23950.


> syntax. This "user input" format would not be an interchange format
> for tranfer across systems, it would be converted at the client
> system to CQL before transfer. Its purpose would be to give a client

And what could that be? CQL, Isearch or .. and at the end of the day it
would be just another flavour of ice cream...
 
> developer a standard syntax on which to build a user interface.
> Long story short, this effort never got off the ground. My point is
> that this is what I think of as a "standard for user input".
>
> Bottom line is, we are not developing a format for user input.
> Whether we are developing a human readable format is a different
> question and I think the answer is that it is human readable to the
> extent that ISO 8601 is human readable, which (as I said above) is
> in the eyes of the human.
>
> --Ray


--

Edward C. Zimmermann, NONMONOTONIC LAB
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967