W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 1999

Re: W3C XML QL and DASL

From: Eliot Christian <echristi@usgs.gov>
Date: Thu, 11 Nov 1999 14:36:40 -0500
Message-Id: <4.2.0.58.19991111143235.00941b90@opsmail.er.usgs.gov>
To: www-webdav-dasl@w3.org
At 09:26 AM 1999-11-09 +0100, Jim Davis wrote:
>[...]
>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.

There is an opportunity to designate a liaison between DASL and the 
XML Query Working Group. I'd be willing to do it if that's OK with 
the group and no one else would rather do it.

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

BTW, is there anyone in the DASL community monitoring the work on 
XML Encoding Rules in ASN.1? I've been thinking it might be a real 
good idea to have an ASN.1/XER specification of the DASL protocol. 
In addition to having a precise specification for on-the-wire 
interoperability, you would have a built-in mechanism for DASL 
to be transmitted in a choice of highly efficient encodings.

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

Yep, safe assumption. 


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

Yep, that is assumed in this case


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

This is certainly our working assumption


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

If you feel statelessness is important, I will need to get 
clarification about the assumptions on the XML Query side. 
My guess is that the response will be that result persistence 
should be implementation-specific. Perhaps implementations that 
do not persist a result set could require that the handle for 
retrieving a set member is processed as a query with a 
"piggy-backed" request for presentation. Does this sound 
like what DASL would expect? 

>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?)

Name is the human-readable part of the link to a result--
what I have in mind is the "title" part of an HTML page, 
typically coerced to a URL or other property in the absence 
of a title. In a typical search "hit list" entry:

<a href="http://host:port/file-name.html">Name</a>

> >(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 am just about positive that the XML Query will be expected to act upon 
and produce XML (more precisely, the XML Query Language operates on an 
abstraction known as the XML Query data model). 

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

OK

This brings to mind that I should do a quick "reality-check" here.

Say I have an object such as a document with properties of "title", 
"author", and "content". An XML Query data model might be constructed 
with title, author, and content as siblings, like:

<root>
   <title>My Doc Title</title>
   <author>John Doe</author>
   <content>When in the course of human events.</content>
</root>  

Alternatively, an XML Query Data Model might be constructed with 
title and author as content attributes, like:

<root>
   <content title="My Doc Title" author"John Doe">
   When in the course of human events.</content>
</root>  

Is it true that DASL is capable of operating on either case? 
(leaving aside whether one is more preferrable than the other)



Eliot Christian, US Geological Survey, 802 National Center, Reston VA 20192
echristi@usgs.gov  Office 703-648-7245  FAX 703-648-7112  Home 703-476-6134
Received on Thursday, 11 November 1999 14:36:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT