RE: HREF Property in Thai Restaurant

Jim Davis wrote:
> Aha.  Now I think I see what the confusion is.  You and I are 
> trying to use the URL for two different things.  Usually we
> want it to stand for the resource being indexed (the  restaurant),
> but sometimes we want it to stand for the index itself.  This is
> why you want to be able to do a PROPPATCH on siamiam.com, to
> change the rating.
> 
> Do you agree that this is the problem?

I have a long reply, but might save a lot of time with a simple
question: In the restaurant example, if I was to do a PROPFIND on the
same object would I get exactly the same back as I would with the DASL
query?

In my previous mails, my assumption was that the PROPFIND HREF value was
the URI of the WebDAV resource, not the restaurant's web site, and
therefore I was raising the question as to why DASL and WebDAV should
return different meanings for the HREF URI. But looking at it again I am
starting to wonder if I have not so much a confusion with DASL, but with
WebDAV! Is the HREF URI in WebDAV the URI of the meta information or the
URI of the information that the WebDAV entry is about?

I think my confusion came because, since I have implemented my WebDAV
layer over a database, I've elided the distinction between meta
information and the resource that the information is about. I assumed
from the spec that I had to set the HREF value to the value of the
WebDAV resource - a bit like the Content-Location header - because all
the sample have it this way. I'm starting to think that what I should
have done is placed the URI of the resource that WebDAV has properties
'about'. As you said, it's only because all the resources are on the
same server as the WebDAV interface that it 'looks' like HREF is
pointing to the WebDAV URL, and not the resource URI. But obviously on
this basis my assumption that there is a difference between what is
returned by DASL and WebDAV is wrong.

I'd guess therefore, that if the HREF is used in this way, then for me
to follow through the scenario I have outlined previously, I need
*another* WebDAV server (or collection) that has as its members the
index entries - one of which is the restaurant entry. This server then
controls the locking and so on, on the index resources, which in turn
refer to the Thai restaurant web site. Just to be sure I have this
right, the first server - the index entries - need only be a level 1
server, since there is no ability to lock the resources referred to -
they are not under your control. The second server would contain
resources that refer to the indexes on the first server, and it is on
this second server that locking goes on, hence it must be a level 2
server.

Am I getting warm? Thanks for your patience.

Best regards,

Mark

Received on Thursday, 18 November 1999 21:40:12 UTC