RE: href in where clause

Julian:

 "...I was wondering whether we need a facility to query the HREF
(which basicsearch currently doesn't have)."

basicsearch is a basic search. Everyone has to implement 
basicsearch. We want the cost of entry to be low. I suggest
using the approach of "If the protocol is useful without it,
leave it out of the first draft."

Alan


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, March 01, 2002 6:09 AM
To: Wallmer, Martin; 'Julian Reschke'; dasl
Subject: RE: href in where clause


> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Wallmer, Martin
> Sent: Friday, March 01, 2002 3:02 PM
> To: 'Julian Reschke'; dasl
> Subject: RE: href in where clause
>
>
> Hi,
>
> querying the display name seems not to be a good idea, as WebDAV does not
> define how the display name should be derived from the href. So different

Agreed.

That's why I was wondering whether we need a facility to query the HREF
(which basicsearch currently doesn't have).

> servers might produce different display names for the same href. Slide for
> example encloses the display name in a CDATA section.

That should be irrelevant. Whether text is returned in a text node or in a
CDATA section doesn't change the XML Infoset.

BTW: why is Slide doing this? To avoid proper XML escaping? Bad idea,
because this way a displayname may not contain the string "]]>".

> So something as you suggested is necessary. Whats about url encoding? It
> could be something like
> <D:where>
>   <D:like>
>     <D:href url-encoding="shift-jis"/>
>     <D:literal>somethingWithSpecialCharacters</D:literal>
>   </D:like>
> </D:where>
>
> url encoding should default to UFT-8

I agree with the structure, but I don't see why we would want to specify an
encoding. The encoding must be UTF-8 anyway, otherwise there wouldn't be any
interoperability in WebDAV.

The other issue is that the format of the HREFs may be different across
servers (protocol and authority may be missing, possibly trailing
slashes...).

Received on Friday, 1 March 2002 16:18:43 UTC