RE: Issue #5: compound DAV:resourcetype property for references.

Hum.... Jim's argument definitely gives me food for thought.

Let's look at this from an implementation point of view:

A reference resource type isn't something you can just layer on top of an
existing resource. You need to take over ALL the methods so as to make sure
you do the right thing in forwarding/not-forwarding. In the case of ISAPI,
however, it is possible to register DLLs in order. Thus I could imagine
implementing a reference by having the reference DLL go first and if the
message is a no-passthrough then letting it continue to the underlying
implementation of features such as PROPPATCH. Either way the DLL
implementing the reference is going to have to have some relationship with
the property system (either because it implements its own or re-uses someone
else's) so it can set properties.

So in terms of implementing a reference there doesn't seem to be a big
difference between putting reftarget in resourcetype and putting reftarget
in its own property.

For the purposes of search the question becomes more interesting. I would
really like resourcetype to be one stop shopping for a complete description
of the resource's type. Thus it is likely to be filled with lots of stuff.
Hence the hope that two resources with the same reftype and refintegrity
will have the same resourcetype is probably unrealistic. Who knows what
other information will be in there. Search mechanisms will have to be able
to just pick out the parts of the resourcetype that they are interested in.
Thus putting reftarget into resourcetype doesn't seem to have any downside
from a search point of view.

I suspect the main reason that I really dislike having reftarget as its own
property is that some brilliant person will come up with the astoundingly
original suggestion that one can change the reftarget by doing a PROPPATCH
on the reftarget property. For reasons I have beat to death in the WebDAV
Book of Why
(http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0302.html) I
think this is a bad idea. Hence I sleep better at night knowing that
reftarget is inside of a read only property, resourcetype.

But, unfortunately, you can't ban idiots. If they can do something stupid,
they will do something stupid. So it would appear that in the end this is
really just a matter of esthetics. Which sounds like a coin flip and coin
flips should always go to the authors.

			Yaron


> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Friday, February 26, 1999 10:04 AM
> To: WEBDAV WG
> Subject: Issue #5: compound DAV:resourcetype property for references.
> 
> 
> At 03:07 PM 2/22/99 PST, Yaron Goland wrote:
> 
> [Yaron sent one large message with many issues, but I think 
> it will help to
> address each one in a separate message.  Indeed, all things 
> being equal, I
> would request all those who comment to keep to one issue per message,
> otherwise the messages get quite lengthy, and the threads 
> become tangled.
> but I am very grateful for the comments, and given a choice 
> between one
> omnibus message and silence, I must prefer the big one.  thanks YG]
> 
> >> > (Issue #5) Section 4.3.1 - ... 
> >> > DAV:reftarget, DAV:reftype
> >> > and DAV:refintegrity ...  
> >> >  values [should be] 
> >> > included inside the DAV:reference element in the 
> >> > DAV:resourcetype property?
> 
> I agree with Yaron, at least for reftype and refintegrity.
> 
> An example
> <dav:resourcetype>
>   <dav:reference>
>    <dav:reftype><dav:direct/></dav:reftype>
>    <dav:refintegrity/>
>   </dav:reference>
> </dav:resourcetype>
> 
> but as for the reftarget, my intuition says it does not part 
> of the "type".
>  if I have two different references, with different targets, 
> but otherwise
> the same (both are direct references with no integrity) then 
> they should be
> exactly the same "resourcetype".
> 
> Judy's rebuttal (that DASL oesn't (yet) support searches on structured
> properties) is best answered by saying that that is a problem 
> (perhaps) for
> DASL.   The DASL team choose (wisely, I think) to postpone 
> addressing this,
> but this is no reason that all of WebDAV must forever be restricted in
> design choices.
> 
>

Received on Friday, 26 February 1999 14:13:38 UTC