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

> From:
> []On Behalf Of Jim Davis
> Sent: Tuesday, May 28, 2002 6:22 AM
> To:
> Subject: RE: comment on issues in DASL draft: query on href
> Lisa Dusseault proposed a use case and gave several examples.  I think I
> could summarize her use case as the observation that it is often the case
> that the URL (the href) of a resource is meaningful and hence useful to
> search.  It's true that the href might not be meaningful in all
> cases, but
> it is certainly meaningful in at least some cases, and enough to be worth
> consideration.
> I think she's right.

So do I.

> But first let's clear up a confusion about the displayname property.  RFC
> 2518 defines the displayname property (13.2) as "a description of the
> resource that is suitable for presentation to a user".  The examples make
> clear that this is intended to be a plain text description, not a copy of
> the href, so a typical display name might be "How to wreck the california
> energy economy" as opposed to "".  RFC
> 2518 makes no promises that you'll find anything related to a
> "filename" in
> the displayname.
> This does not affect the validity of Lisa's use case in the
> slightest.  it's useful to be able to search display name, and, in some
> cases, it would also be useful to search the href, if only this
> were possible.
> Luckily, I think it is not only possible, but easy.  While it is true
> that  RFC 2518 does not define an href property, DASL is not
> restricted to
> searching only those properties defined by RFC 2518.   In theory, any
> property could be searched.  So if a DASL search arbiter wants to support
> search on a property whose name is DAV:href, there is no obstacle.
> ..

Yes, there is. DASL should't get into the business of defining new pseudo
properties. If something needs to be queryable, but isn't a WebDAV property,

- either make it a full-blown WebDAV property, or
- don't use a property to express the query condition.

Another issue with DAV:href being a property is that depending on the
server, the href may be a full absolute URI (including protocol, host,
port...), a relative URI reference starting with "/" or even a relative URI
reference (not starting with "/" and relative to the parent collection). So
we would have to define what this property really is, and it couldn't be the
same thing as the DAV.href *element* for all servers.

Another possible approach would be to require resolving the HREF to an
absolute URI before matching.

So if we really need to provide this feature, I'd define a new construct

      <D:binding-name/>	<!-- borrowed from RFC3253 -->

which of course would only work for the last path segment.

Received on Tuesday, 28 May 2002 03:55:09 UTC