RE: comment on issues in DASL draft: query on href

> "DAV:href isn't a property, so it can't be used in
> queries. Is this a problem? Examples where DAV:displayname
> is queried instead seem to indicate that. A possible
> solution would be to allow DAV:href whereever DAV:prop is
> allowed in the where clause."
> I don't think it's a problem.  Can any one provide a use case that is
> impossible because of this?  note that DASL is for searching WebDAV
> *resources* not for searching the name space of URLs.

One case is when I'm looking for a resource that I know to have the last
path part of "file.doc", but I don't know what collection it is in.  The
display name *could* be set to "Overview of document stuff".  I know most
WebDAV servers use displayname as if it were equal to the last path part,
but this is not a MUST, just a convention.  Some might allow displayname to
be a friendly name, particularly since the last path part is already (for
all purposes so far except DASL) clear from the href.

Another case is when I'm looking for information in my repository about a
customer 'mit'. I want to see what presentations, requests for comments,
etc. are so closely tied to MIT that they have that string in the name.  I
could search the set of displaynames for the string 'mit'.  However, that
could miss a whole set of documents:
It's true that the collection /customers/mit/ would be returned in the
search, but none of its children would have the string 'mit' in their
displaynames, so none of them would be returned in a displayname substring

One could define both these as cases of searching namespace of URLs, not
resources, and hand-wave away the problem. I don't think the definition
matters as much as the fact that these are possible DASL use cases, and we
can decide whether or not to support these use cases based on their
importance (and difficulty) as use cases.


Received on Monday, 27 May 2002 22:24:01 UTC