- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 14 Dec 2001 22:55:53 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "Julian Reschke" <julian.reschke@gmx.de>, <www-webdav-dasl@w3.org>
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