RE: Issue: BIND and MKRESOURCE

It sounds like you're trying to create a relationship between two different
resources that happen to have the same content. This is application
dependent behavior that should be enabled, but not necessarily supported by
WebDAV.  To do this you could create an empty resource for your new
properties and establish a link between the resources using application
specific properties. The protocol lets you do all of this, and your
application can maintian the semantics as needed.




                                                                                                                 
                    "Adam Freeman"                                                                               
                    <afreeman@lightsur       To:     "Clemm, Geoff" <gclemm@Rational.Com>,                       
                    f.com>                    <w3c-dist-auth@w3.org>                                             
                    Sent by:                 cc:                                                                 
                    w3c-dist-auth-requ       Subject:     RE: Issue: BIND and MKRESOURCE                         
                    est@w3.org                                                                                   
                                                                                                                 
                                                                                                                 
                    04/21/2001 11:06                                                                             
                    PM                                                                                           
                    Please respond to                                                                            
                    afreeman                                                                                     
                                                                                                                 
                                                                                                                 



Hi,
I guess what I am asking then is if something can be added to the spec that
will basically create a link from the copy to the original whose sole
purpose is to have different metadata associated with the link than the
original resource.  There may be a problem here with live properties but
maybe it's up to the people who would be using this property.  I guess it
would look something like this -->
>> Request:

MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
Host: www.ics.uci.edu
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx

<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
   <D:set>
      <D:prop>
         <D:resourcetype><D:directref-metadata/></D:resourcetype>
         <D:reftarget>
            <D:href>/i-d/draft-webdav-protocol-08.txt</D:href>
         </D:reftarget>
      </D:prop>
   </D:set>
</D:propertyupdate>

>> Response:

HTTP/1.1 201 Created

A specific case I can think of where this would be useful is if you had
image data but had different operations on this image data depending on the
resource.  Like you might want to have different scaling operations applied
to the image data so you could look at it at different resolutions for each
of the different resources.  (In this case, the live property
DAV:getContentLength might be changed to reflect the different content that
was being returned, or maybe not depending on what the user of the property
wants).

What do you think?
- Adam




-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
Sent: Saturday, April 21, 2001 12:05 PM
To: w3c-dist-auth@w3.org
Subject: RE: Issue: BIND and MKRESOURCE


Redirecting GET and not PROPFIND would produce some rather
surprising results, since a variety of live properties describe
aspects of the content (e.g. DAV:getcontentlength, DAV:resourcetype),
which is why a redirect reference is defined as acting uniformly
across all operations.

The DAV:source property is just informative ... setting or modifying
it on a resource does not modify the result of operations applied
to that resource.

So there is currently no interoperable way to produce the result
you have in mind.

Cheers,
Geoff


-----Original Message-----
From: Adam Freeman [mailto:afreeman@lightsurf.com]
Sent: Thursday, April 19, 2001 3:23 PM
To: w3c-dist-auth@w3.org
Subject: Issue: BIND and MKRESOURCE


Hi,
I am a new subscriber to this list and have just started checking out
WebDAV.  I've been reviewing the memos for BIND and MKRESOURCE for
redirecting references.  What I would like to do with WebDAV is create a
new
resource that references an original resource but with different metadata
(MKRESOURCE can be used to do this).  The problem is MKRESOURCE will make
it
so that a redirect (302) is sent back to the client but I would like to
send
back the original resource bits.  This is pretty much what BIND is supposed
to do except that BIND also returns back the same metadata information for
the bound uri as the original.

It makes sense to me that a DAV server could *either* send back a 302 or
the
original bits given the resourcetype of the resource ... ?

I managed to hack this by creating a soft link on the server using ln -s
and
then I could have different metadata for the reference than the original
but
have both return the original bits.

For example,

    wh24.jpg
    wh24.ref -> wh24.jpg

where wh24.jpg and wh24.ref have different metadata on the DAV server.

Also, is the <link><src/><dst/></link> property supposed to do what I am
trying to do.  If so, I couldn't figure out how to use it properly.  I
tried
placing the property in the root collection like this -->

<prop><source><link><src>http://server/wh24.jpg</src><dst>http://server/wh24

.ref</dst></link></source></prop>

but when I try to access wh24.ref on the server I get a 404.

Thanks,
Adam

Received on Saturday, 21 April 2001 23:54:57 UTC