Print

Print


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