Re: W3C XML QL and DASL

At 06:14 AM 11/7/99 -0500, Eliot Christian wrote:
>I am involved in the W3C XML Query work, which has a specific 
>requirement to coordinate with the IETF DASL work. The XML 
>Query work needs to address protocol issues up front and also 
>needs to document some Use Cases to help focus the work.

Eliot, it's nice to hear from you again.  I am delighted that the W3C XML
Query group has taken on the requirement to coordinate with DASL.  Thanks
for writing.

>I offer for consideration the following Use Case as a way 
>to introduce some of the protocol considerations of an 
>application using XML Query. I would very much like to know 
>if you think this makes sense from the DASL perspective, 
>and especially any specific suggestions to improve it ;-)

The scenario makes sense within the DASL perspective.  Not all the behavior
in it could be done with DASL's basicsearch, but as you probably realize,
basicsearch is intentionally kept simple for ease of implementation.

In general, I think that *any* XML query syntax your group select will work
fine with DASL as long as the query can at least be transported in XML
itself.  Some of the propoposed syntaxes use XML all the way, and others
are just strings, but even the latter could be at least transported as
PCDATA.  Depending on the semantics, the query could either be an extension
to basicsearch or might require a new DASL "query grammar".  

Now to turn to the details of your note.

>---------------------------------------------------------
>
>XML Query Use Case: Referral Search
>
>In this case, the user of XML Query begins with a text 
>search at a referral service, using just one English word. 

This could easily be done with DASL basicsearch, assuming that each
collection is also a Web resource of some kind and possesses a URL.

>This results in a number of candidate collections, each one 
>titled and ranked by score. The user selects a collection 
>and gets a more precise search facility that is particular 
>to the selected collection.

This fits, if one assumes that the collections are not only resources, but
are themselves DASL search arbiters.  That is, the first search was on an
arbiter that indexes other search arbiters, each of which supports its own
"more precise search facility"

>     The user constructs a Boolean 
>XML Query and then receives a set of document scores and 
>titles which satisfy the query. 

This fits too, assuming one can fit the XML query language into DASL (which
I think is very probably true.)

A few of the detailed steps deserve special comment..

>(2) Server - The designated service processes the query 
>against the designated collection of XML documents, applying 
>criteria appropriate for a full-text search. The service 
>causes delivery to the client of XML representing a named 
>"result set" pointing to XML documents within the collection 
>that satisfy the query. Each member of the result set has a 
>structure composed of a score for the set member, a name for 
>the set member, and a handle for retrieving the set member 
>(e.g., URL). 

In DASL's basicsearch result sets are not persistent.  This was done to
lower cost of implementation.

Every result in the result set has a handle, which is always a URL.
Support for score is optional.  No one has asked for a "name" property,
since the handle, being a URL,  is always unique not only in the result set
but across the entire universe.
(Or perhaps I misunderstand what the "name" is?)

>(4) Server - The service retrieves the XML document 
>designated by the set member retrieval handle and causes 
>delivery of the XML document to the requesting client. 
>This XML document itself describes another collection of XML 
>documents available on a service elsewhere. Its structure 
>includes a service title, a pointer to the schema for the 
>collection, and a handle for accessing the collection 
>(e.g., a URL including the service host:port and named 
>structure in a file system).

In DASL one could do this two ways:  
 1) the resources being searched could have a set of properties to the same
effect, e.g. service title, schema pointer, etc.  These would be WebDAV
style properties.
 2) The resource could be an XML document containing the same info.

I think the former is nicer, since it uses an existing mechanism (WebDAV)
to access the properties, it allows one at least the potential of other
remote operations on the resource (e.g. changing the title) though WebDAV
itself, which also allows a nicer granularity of operation - one can change
*just* the title, and nothing else, by doing a WebDAV PROPPATCH on that one
property.

But if you really want the latter, you can have it with DASL.  In this
case, there's no difference between an XML document and, say, a GIF fle
(except there's no nasty patent on XML :-).  but in either case the
document is opaque to DASL itself.

Best regards

Jim

Received on Tuesday, 9 November 1999 12:44:36 UTC