RE: JW10: QSD usage

Jim:  

First, operators: Since there are so few, I would
expect most UI's to implement all of them. However,
I know for at fact that not all repositories (as opposed 
to UI's) implement contains. So, it is in fact an obvious 
benefit to provide this information -- the UI can grey 
out or leave out the operators, e.g., contains, that 
are not implemented in a particular repository.

Second, properties: It is most definitely a
benefit to provide the properties that are
supported, have the UI display them, and have the UI
allow the user to select only the supported properties
with the mouse. Look at any of the query UI's that my
company or a lot of other companies ship.
It's sort of de facto standard approach to query UI's
on higher end systems, and for good reasons.

Alan Babich

-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Thursday, June 24, 1999 5:02 PM
To: 'DASL'
Subject: RE: JW10: QSD usage



> I would have thought that the use of QSD is too obvious to explain.
> The client UI could offer pulldowns for properties, operators, etc.
> if QSD provided such information. Pulldowns could be used to
> preclude typing and spelling errors, etc.

I don't buy this.  If I'm writing a client, do I really want to allow random
search operators into my user interface, where there will be an expectation
on the part of customers that I will provide customer support for operators
I never developed?  It seems more likely that I will only understand a
limited set of operators, and provide a user interface for just those
operators, ignoring all others that happen to be present.  In fact, in this
case I'm likely to never do QSD, instead just sticking to the base set of
operators supplied for a given schema.

- Jim

Received on Thursday, 24 June 1999 20:43:05 UTC