RE: DASL draft issue: identification of query grammars

Ok,

given a URI reported in the DASL header of OPTIONs, how do I find out
whether it stands for a specific XML based grammar? There is no direct
mapping from a URI to a qualified XML element name, yet that's what's used
as a child of the <searchrequest xmlns="DAV:"> element.

Or do you propose to keep a hardwired mapping for each query grammar your
software knows about?

Julian

> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, December 14, 2001 10:38 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: 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:56:00 UTC