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

RE: deltaV (draft 14) questions

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 12 Apr 2001 00:07:07 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B102A7593B@SUS-MA1IT01>
To: WebDAV WG <w3c-dist-auth@w3.org>
   From: Julian F. Reschke [mailto:julian.reschke@gmx.de]

   a few questions/comments:

   1) 2.2.4	DAV:supported-live-property-set (protected)

   <!ATTLIST supported-live-property namespace NMTOKEN "DAV:">
   namespace value: an XML namespace

   This seems to indicate that only properties in the DAV: namespace
   can be live properties, which I think is wrong.

The NMTOKEN "DAV:" construct just says that if no namespace
attribute is specified, it defaults to "DAV:".  An explicit
namespace attribute overrides this default.

   2) General comment regarding new required properties for all resources

   Unless I'm making a mistake, this makes propfind/allprop extremly
   chatty...

In 14.1, we have added the statement that a server SHOULD NOT return
any versioning properties in an allprop PROPFIND.

   Regarding "supported-method-set" -- what is it for? If I really
   would need to know this, couldn't I just do OPTIONS on the
   resource?

You often want to populate a "tree explorer" GUI with this
information.  If it is a property, you can use a Depth PROPFIND to get
this information for the whole tree in one request.  Otherwise, you
would have to do a separate OPTIONS call for every member of the tree.

   Regarding "supported-live-property-set": this *is* very useful, but
   it seems it could be implemented simpler and more effective by
   extending propfind/propname to include this information, for
   instance:

   >>Request

      PROPFIND  /container/ HTTP/1.1
      Host: www.foo.bar
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <propfind xmlns="DAV:">
	<propname includeTypeInfo="yes"/>
      </propfind>

   >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml; charset="utf-8"
      Content-Length: xxxx

      <?xml version="1.0" encoding="utf-8" ?>
      <multistatus xmlns="DAV:">
	<response>
	     <href>http://www.foo.bar/container/</href>
	     <propstat>
		  <prop xmlns:R="http://www.foo.bar/boxschema/"
   xmlns:dav="DAV">
		       <R:bigbox dav:type="dead" />
		       <R:author dav:type="dead" />
		       <creationdate dav:type="protected" />
		       <displayname dav:type="live" />
		       <resourcetype dav:type="protected" />
		       <supportedlock dav:type="protected" />
		  </prop>
		  <status>HTTP/1.1 200 OK</status>
	     </propstat>
	</response>
      </multistatus>

   Obviously this could also be made propfind/propinfo (new propfind
   type), and it could also use child elements rather than attributes
   (<creationdate><protected /></creationdate>...).

The "live-property" property effectively provides the basis for this
query (i.e. the detailed information will appear as child elements of
the live-property element).  In general, nested elements are better
than attributes, since element values have structure while attribute
values are just strings.

   3. 2.1.1	Creating a Version-Controlled Resource and
      2.3.1	DAV:checked-in (protected)

   OK, under core versioning, every version is a resource on it's own.
   Does this mean that a server has to assign a unique URL and make
   the version resource visible under this URL, for instance for
   PROPINFO? Or is this optional?

It is required.

Cheers,
Geoff
Received on Thursday, 12 April 2001 00:05:46 GMT

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