RE: DASL draft issue: identification of query grammars

It's true that DASL uses URIs to identify query grammars.

What makes you say that XML-based query grammars need to be identified by a
QName?

Lisa

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> Sent: Friday, December 14, 2001 1:14 PM
> To: www-webdav-dasl@w3.org
> Subject: DASL draft issue: identification of query grammars
>
>
> Hi,
>
> see the message below for a DASL issue we discussed privately
> before and for
> which we'd like to see feedback from others.
>
> The issue is that the current (expired) DASL draft uses URIs to identify
> query grammars, however XML-based query grammars need to be
> identified by a
> Qualified XML name (a pair of namespaceUri reference and local name).
>
> Julian
>
> > From: Jim Davis [mailto:jrd3@alum.mit.edu]
> > Sent: Monday, November 19, 2001 5:45 AM
> > To: Julian Reschke; Lisa Dusseault
> > Cc: mcc@watson.ibm.com; Jim Whitehead
> > Subject: RE: DASL spec issue: encoding of a query grammar
> >
> >
> > Julian last wrote about this issue in mid-September.  If it has been
> > solved, you can ignore this.  If it's still alive, we should try
> > to solve it.
> >
> > Maybe it will help if I try to explain what the DASL authors were
> > trying to
> > accomplish.  if there is a better way to meet the same goal,
> that's fine.
> >
> > The problem we need to solve it having a globally unique way to
> name query
> > grammars. our proposed solution is to use a URI as a name for
> the grammar.
> > So, e.g. we want to say "this query uses the query grammar
> defined by the
> > Library of Congress for complex boolean bibliographic queries" and "this
> > server will accept queries in any of the following N grammars".  Query
> > terms have meaning only with respect to some grammar,
> >
> > now, is the way we proposed to do this in DASL sufficient for
> this?  Note
> > that DASL does not need to combine the grammar URI and the query term
> > string to make a longer URI, so I do not think any parsing is required.
> >
> > If there is a better way to meet the same goals, I for one, do
> not object
> > to using it.  If so, please say what this is, or (so far as I am
> > concerned)
> > just change the spec to use it.
>
> In my eyes, the most elegant way would be just to copy the way
> the supported
> REPORTs are reported (see deltaV spec). Basically, there'd be a computed
> live property named DAV:supported-search-grammar-set like:
>
> <supported-search-grammar-set xmlns="DAV:">
> 	<supported-search-grammar><basicsearch /></supported-search-grammar>
> 	<supported-search-grammar><syntax1
> xmlns="http://foo.bar.com/"/></supported-search-grammar>
> 	<supported-search-grammar><syntax2
> xmlns="http://akuma.com/"/></supported-search-grammar>
> </supported-search-grammar-set>
>
> Advantages:
>
> - in line with other DAV standards
> - solves discovery of grammar names properly
> - doesn't require additional headers in OPTIONS
>
> Disadvantages:
>
> - will only work for servers that support PROPFIND
>
> Now, is the latter really still a problem? The DASL draft contains a few
> hints that SEARCH requests with non-XML content should be
> possible, yet it's
> silent about how this should work.
>
> Julian

Received on Friday, 14 December 2001 16:40:30 UTC