RE: HREF Property in Thai Restaurant

Jim Davis wrote:
> So, just to elaborate, if one does a DASL search and gets 
> back a result
> with some URI and some set of properties, one should not 
> expect to be able
> to do a PROPFIND on that URI  to read the same set of 
> properties.    One
> should certainly not expect to be able to do a PROPPATCH (the Thai
> restaurant would like to increase its rating to five stars 
> but alas it can not)
> 
> [snip]
>
> Do you see a problem in this?

Let's just say for the moment the justification eludes me!

I follow the reasoning. So much so that when I first read the DASL stuff
I thought, "aha - just what I need". However, when I began to look at it
in relation to what I had already implemented over on the WebDAV side, I
started to feel that it didn't quite gel.

My major problem is that you can get two different results back
depending on how you formulate the question. If I issue a PROPFIND to
some server, saying give me the properties of the entry for Siamiam, I
get back:

  <D:response>
    <D:href>http://ryu.com/siamiam</D:href>
    <D:propstat>
      <D:prop>
        <D:xxx />
        <R:location>259 W. Hollywood</R:location>
        <R:rating><R:stars>4</R:stars></R:rating>
      </D:prop>
    </D:propstat>
  </D:response>

The server has some object which is at a known location which contains
WebDAV info - is it locked? when was it created?, etc. - as well as info
from another namespace. So under normal WebDAV operation I am able to
access all properties of an object. Now, if I want to find all objects
that are currently locked out to a particular user, or all objects
created after a certain date, I am assuming I have to move to DASL. Yet
when I do formulate such a query in DASL, I'll get:

  <D:response>
    <D:href>http://siamiam.com/</D:href>
    <D:propstat>
      <D:prop>
        <D:xxx />
        <R:location>259 W. Hollywood</R:location>
        <R:rating><R:stars>4</R:stars></R:rating>
      </D:prop>
    </D:propstat>
  </D:response>

So how do I delete all items created before October 1st, or unlock
everything that is locked out to a particular user? With this
configuration an attempt at deleting index entries for all 4 star Thai
restaurants would try to delete their web sites! And - to answer your
question with another - why shouldn't I be able to do a PROPPATCH? Sure
the restaurant shouldn't be able to up their star rating, but that's a
security issue.

My feeling so far is that this approach caters for one use of DASL,
which is to hold indexes to other resources. But by gearing everything
to that, don't we lose the ability to search the index entries
themselves?

To pose it a different way; why should the format of the result of a
PROPFIND on a known URI be different to a DASL query on some container
that includes that same URI? In other words, there is no notion of "what
are the properties of this object", since the answer is "depends on how
you ask the question".

If I'm missing something feel free to point it out!

Best regards,

Mark

Received on Monday, 1 November 1999 13:34:54 UTC