W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: expand-property report (was: Re: remove DAV:version property?)

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 25 Jan 2001 22:31:32 -0500 (EST)
Message-Id: <200101260331.WAA25382@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   On Thu, Jan 25, 2001 at 05:45:31PM -0500, Geoffrey M. Clemm wrote:

   >    ...  [ also note that expand-property "violates" DTDs for
   >    properties. cool with me, but some DTD fanatics will be up in
   >    arms. (e.g. version-history isn't defined to contains a
   >    DAV:response element) ]
   >
   > ... I will address this point by adding some appropriate text
   > to the DAV:expand-property section describing this DTD-extending
   > impact, and not by modifying the DTD's.  Is this OK?

   Don't bother. I only mentioned it to tweak the DTD purists :-)

I added a sentence in the 12.1 draft, but could just take it back out
if folks think it is unnecessary.  Any preferences?

   DAV has the overall design point of "other elements may appear within DAV:
   elements; ignore those that you don't understand." This is a simple case of
   that.

Well ... I'd maintain that a client that issues the
DAV:expand-property request MUST understand that DAV:response nodes
can replace DAV:href nodes, so I don't think it falls under the
"ignore those that you don't understand" case, but rather the
"know the semantics of the request you just made" case (:-).

   However, now that I'm thinking about it... it *is* important to note that
   any DAV:response embedded within the "property value" is not actually part
   of that value.

I believe that should be clear from the fact that you are not getting
a property value back, but rather an "expanded" property value.  So
although the DAV:response is not part of the value, it is part of the
DAV:expanded-property report.  But if you think that might be unclear,
I'd be happy to add a sentence to that effect (unless you are going to
have me just take it out again :-).

   Hmm... Normally, we have a value such as:

     <D:version-history>
       <D:href>value</D:href>
     </D:version-history>

   In the expand-property report, the D:href is moved:

     <D:version-history>
       <D:response>
	 <D:href>value</D:href>
	 <D:propstat>...</D:propstat>
       </D:response>
     </D:version-history>

Well, I think it's simpler to just think of the DAV:href as being
replaced by a DAV:response node (which just so happens to have
a nested DAV:href node), rather than thinking about the DAV:href
node being moved somewhere.

   Personally, I think that is fine, but maybe it needs a bit of clarification.
   Especially from that standpoint of "what if other value(s) are in that
   property?" For example:

     <D:version-history>
       <D:href>value</D:href>
       <SVN:extension>something</SVN:extension>
     </D:version-history>

   Where does the SVN:extension go? Using the "href -> response" rewrite angle,
   the result would be:

     <D:version-history>
       <D:response>
	 <D:href>value</D:href>
	 <D:propstat>...</D:propstat>
       </D:response>
       <SVN:extension>something</SVN:extension>
     </D:version-history>

   Given the above, clarification might be essential :-)

Is there any other possible interpretation, given that the report is
defined as "replacing the DAV:href node with a DAV:response node"?

Cheers,
Geoff
Received on Thursday, 25 January 2001 22:32:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT