RE: JW10: QSD usage

Jim Whitehead:

I don't think we're on the same wavelength. I think we're
probably talking past each other. The question you
asked ("... client A can submit a DASL query to server X and 
have it succeed, and submit the same query to server Y and have 
it not succeed because server Y doesn't index the same properties 
as server X.  Is this correct?") doesn't relate to the
paragraph you quoted below.

If one understands DASL, then one understands that any well formed
query "succeeds" on (i.e., can be successfully submitted to) 
any document space (these are called "scopes"), 
but doesn't necessarily produce any results. 
(This is true whether or not the properties 
mentioned in the query are supported by any or all of 
resources in the target document space. That is
because DASL specifies in detail whether or not a resource
satisfies a query condition regardless of whether or 
not the properties in the query condition are supported 
by the resource or not, and, if supported, whether or not
they have a non empty value, and whether or not the
operators are supported.) Therefore, if you understood 
DASL, you would not have asked the question of whether a 
query "succeeds" or not. The answer is always "Yes, it 
succeeds".

Efficiency is another issue. Obviously, when a large
number of resources are involved, indexing or some other
technique is important for efficiency. And yet, a query 
must produce exactly the same results regardless of what 
properties are indexed or not indexed. However, DASL makes 
no mention of indexing. DASL queries
do not allow expression of the requirement that certain
properties be indexed. DASL queries will not fail because 
some property mentioned in the query is indexed or not 
indexed. It is up to the document space to implement
queries efficiently.

Your real concern is interoperability. Note that efficiency 
is not the same as interoperability. I don't see the
interoperability problem you're concerned about.

Now, let's discuss the paragraph you quoted.
Suppose you write a UI. Suppose you want to do a good
job. Then, you could do the following. You let your user 
express his intent to query document space A. 
Your UI program then goes to document space A,
does query schema discovery, and makes lists of the
properties and operators supported. Assume that document
space A supports query schema discovery (QSD). Now, 
whenever the user formulates a query, your UI makes 
him select the properties and operators from the 
pulldown list your UI developed from the QSD.
This eliminates all possibility of certain types
of errors the user can make -- spelling errors for
property names, selecting operators that aren't supported
by document space A, etc. That is why this is a
standard way high end systems do it.

Now, suppose the user wants to query document space B.
Then, your UI program discards its lists of properties
and operators, performs QSD on document space B, and
develops new lists for document space B. 

Etc.

Very low end document spaces that do not support QSD preclude
developing pulldown lists. There are two cases. Either
the properties and operators are hardwired into a specific
very low end UI application, or the UI is generic. 

In the first case there is no discussion -- there is no 
attempt at interoperability by the very low end application. 
The UI is proprietary to the specific application. 

In the second (i.e., generic) case, 
the user will have to type in the property names and operators, 
and then see what comes back when he issues a query. 
What comes back is well defined. 

We made QSD optional in order to be more inclusive 
of very low end systems. It was argued that there might be
some very low end systems that don't have a central database
schema, and so don't conveniently know what properties
are supported. Such very low end systems would have to scan 
every resource and take the union, and we didn't want to
impose this burden on them. Let the marketplace force that
burden on them if, indeed, the marketplace deems that to be
desirable. All UI's can rely on all the operators except
possibly "like" and "contains" being supported.

Now, let us look into the future. Suppose DASL as proposed 
succeeds, and the next version of DASL wants to provide the 
ability to query across multiple document spaces as if they 
were one big document space. Then I can think of no better
model than the DMA model. First, the user selects a specific
set of document spaces to query over. Then, the UI performs
QSD over all of them. The user decides to limit himself to
the properties and operators common to all of the document
spaces (less likely), or not (more likely). In the first
case, the lists of properties and operators supported by
the document spaces are intersected. In the second case,
the union of the lists is taken. (This assumes that QSD
is supported by all of the document spaces.) Either way,
the user visible operation for the collection of document spaces
is the same as the operation described above for a single
document space -- the user pulls down the properties
and operators he wants when composing his query. Under the 
covers, the UI sends the query to all the document spaces
and merges the results that come back.

So, I don't understand what your interoperability concern is.

Alan Babich

-----Original Message-----
From: Jim Whitehead [mailto:ejw@ics.uci.edu]
Sent: Tuesday, July 20, 1999 2:46 PM
To: Babich, Alan; 'DASL'
Subject: RE: JW10: QSD usage


> 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.

I've been thinking about this aspect of QSD, and I have some concerns.
Perhaps I'm misunderstanding, but it appears we're creating a situation
where a client A can submit a DASL query to server X and have it succeed,
and submit the same query to server Y and have it not succeed because server
Y doesn't index the same properties as server X.  Is this correct?  Or would
it be the case that both queries would work, but the query on server Y would
be much slower because the searched property isn't indexed?

My concern is with interoperability.  If it is the case that the same query
might not work from server to server, it will be very difficult to develop
clients that use searching, and could lead to lack of adoption of the
protocol.

- Jim

Received on Wednesday, 21 July 1999 15:48:16 UTC