RE: HREF Property in Thai Restaurant

At 02:41 AM 11/19/99 +0000, Mark Birbeck wrote:
>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?

While nothing in the protocol document requires that this be the case, I
think the answer is yes, subject to access control.

>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! 

I am now convinced that the restaurant example is doing more harm than good.

In the PROPFIND response, no matter whether it comes from WebDAV or DASL,
the URL in the href is the URL from which the properties were obtained.

I wrote the restaurant finder example.  In that example, the href value is
intended to be the URI of the Website of the restaurant.  There is no URI
for the metadata itself.  This is perfectly legal, but leads to a lot of
confusion because in this case, just as you have said
 1) A  PROPFIND on the URI might well fail.  The restaurant website does
not even know that it is in the restaurant finderdatabase.
 2) The restaurant finder database does not provide any means for you to do
a followup PROPFIND or PROPATCH on the resource it returns

All of this is legal, but confusing.

> Is the HREF URI in WebDAV the URI of the meta information or the
>URI of the information that the WebDAV entry is about?

In WebDAV there is absolutely no distinction whatsoever.  The URI in the
href is the URI of the resource that the properties are "about".
(Properties are the metadata.)

In earlier email on this thread I described how I should have done things.
The DASL result should be a response where the uri in the href is the uri
of the "metadata resource" on the restaurant finder web site, and the the
URI of the restaurant itself is just another property.
Is that clear?


>
>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.

I am not sure I quite get the picture of which resource is which in your
example.  it seems more complicated than I would think is needed, but in
any case I agree that there are  two distinct resources.

http://good-eating.com/i259 ----->
+-------------------------------------------------------
                                                    |  rating:   4 stars
                                                    | reviewed by: Dave
Fielding
                                                    | review of:
http://www.siamiam.com
                                                    | date: 19-11-1999
                                                    | review number 259
http://good-eating.com/i260 ----->
+--------------------------------------------------------
                                                    | rating 2 stars
                                                    | reviewed by  Jim Davis
                                                    | review of
http://www.macdonalds.com
                                                    | date: 17-10-1985
                                                    | review number: 260


etc

Hopefully this picture makes things clearer.  the resources at
good-eating.com are all reviews.  The properties of the review include the
rating, the name of the reviewer, the date of the review, the URL of the
place reviewed and the review number.  the latter would likely be the
primary key if this were stored in a RDBMS

Adding a new review is done by first PUTting a new resource, then setting
some properties on it with PROPPATCH.  You can get all the data by doing a
PROPFIND, and you search by doing a SEARCH.  

On such a server, you certainly want access control (so that only the one
who creates the review can change it) and you also want locking (so that if
two different people both want to add a new review at the same time, they
see a consistent world)

As for the URLs of the places being reviewed, the resources they refer to
are on totally other servers that have no connection at all to good-eating.com

Now does this help?

Received on Sunday, 21 November 1999 11:26:19 UTC