W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Issue: BIND and MKRESOURCE

From: Adam Freeman <afreeman@lightsurf.com>
Date: Sat, 21 Apr 2001 21:46:51 -0700
To: "Jim Amsden" <jamsden@us.ibm.com>, <w3c-dist-auth@w3c.org>
Message-ID: <NFBBIBMJIOBNIGEECJHCEEHHCAAA.afreeman@lightsurf.com>
Hi,
To me, the metadata is the "view" for the "model" and you might want to have
more than one view for your data.  I could put up a zero byte file as the
resource and then have my application-specific stuff return the "real href
of this resource" in the properties of the resource.  Or I could use the
XLink language to send back a chunk of xml or store a .url file or do a soft
link on the server or possibly a variety of other things.  It just seems to
me like this might be a real future need for other applications as well (any
application that wants to have more than one set of metadata for a given
data source).  Instead of forcing users to do some weird hacks, why not
address the need and stick it into web-dav.  So the web-dav server
interprets the resource and sends back the appropriate data.
- Adam

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Amsden
Sent: Saturday, April 21, 2001 8:49 PM
To: w3c-dist-auth@w3c.org
Subject: 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 Sunday, 22 April 2001 00:47:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT