Re: Naive question

From: Jim Amsden/Raleigh/IBM (marjorie@us.ibm.com)
Date: Tue, Sep 12 2000

  • Next message: Geoffrey M. Clemm: "Re: Naive question"

    To: ietf-dav-versioning@w3.org
    Message-ID: <OFEC21658E.CC4B3C75-ON85256958.008360D0@raleigh.ibm.com>
    From: "Jim Amsden/Raleigh/IBM" <marjorie@us.ibm.com>
    Date: Tue, 12 Sep 2000 20:16:49 -0400
    Subject: Re: Naive question
    
    See <jra> tags. But the primary point is that clients will expect the
    version selector to redirect to the target for contents whether the target
    is the default (specified by the DAV:target property of the version
    selector), or explicitly specified in the Target-Selector header. It is
    reasonable that PROPFIND should behave the same way, and except for live
    properties, the spec says it does. I'm only suggesting that we remove this
    special case.
    
    The list of cases you describe below indicate that we are getting close to
    creating too many special cases in the protocol. Version selectors have
    semantics like bind/redirect references, but are not bindings or redirect
    reference resources. So they end up introducing a lot of special cases that
    make the protocol more complicated. Some of these will be unavoidable. I'm
    just looking for ways to reduce them.
    
    
    
                                                                                                                                     
                        "Geoffrey M. Clemm"                                                                                          
                        <geoffrey.clemm@rational        To:     ietf-dav-versioning@w3.org                                           
                        .com>                           cc:                                                                          
                        Sent by:                        Subject:     Re: Naive question                                              
                        ietf-dav-versioning-requ                                                                                     
                        est@w3.org                                                                                                   
                                                                                                                                     
                                                                                                                                     
                        09/12/2000 05:42 PM                                                                                          
                                                                                                                                     
                                                                                                                                     
    
    
    
    
    
       From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
    
       I think there are some problems with what you describe below.   Any
       operation on a version selector should be redirected to the target
       version including PROPFIND/PROPPATCH regardless if a Target-Selector
       header was specified or not.
    
    Why?
    <jra>
    If a method operates on the target of a version selector, it should operate
    on that target regardless of how the target is specified, explicitly in the
    Target-Selector or implicitly in the DAV:target property of the version
    selector.
    </jra>
    
    Some of the reasons that operations on a version selector are not
    just redirected to the current target version include:
    
    - a MOVE of a version selector is different from a MOVE of the
     target version
    
    - a DELETE of a version selector is different from a DELETE of the
     target version
    <jra>
    This is not described in the spec. MOVE and DELETE introduced the most
    difficult issues in the binding protocol. I hope we're not re-introducing
    all those problems with version selectors.
    
    </jra>
    
    - a LOCK of a version selector is different from a LOCK of the
     target version (the lock properties appear on the version selector,
     not on the version)
    <jra>
    Then LOCK is ambiguous. I don't like the protocol using very different
    semantics on the same target URL based on control couples in headers.
    Headers should parameterize the operation, not change its meaning entirely.
    As with the direct and redirect references arguments, if a resource needs
    to be a resource sometimes, and a binding to another resource some other
    times, we need to expose clear protocol for distinguishing them. This is
    not the case for version selectors because sometimes the absence of a
    Target-Selector causes the method to operate on the version selector, and
    sometimes it doesn't. Maybe we need a header to say the method operates on
    the version selector, not the target as in
    Target-Selector:version-selector. Then MOVE or DELETE will (usually) fail
    if the  target is a version not the version selector. Then no special
    cases. This is ugly too, but at least it could be consistent.
    </jra>
    
    - the members of a collection version selector are version selectors
     and versionable resources, while the members of a collection version
     are version histories (this is discussed at length in several earlier
     threads in this mailing list).
    
    - for efficiency (and other reasons), many servers will want to have
     certain live properties of a version selector to be distinct from
     those of the target version, so that the target version does not have
     to be queried/updated whenever the version selector is (and vica
     versa).
    <jra>
    This depends entirely on the properties the client asks for, not the
    semantics of the protocol itself.
    </jra>
    
       The Target-Selector header is only there to
       override the DAV:target of the version selector. We don't want different
       semantics depending on how you specified you version.
    
    I disagree.  The semantics of a version selector are very different from
    those of a version (see above).  The Target-Selector header is there to
    give you a convenient way to access a version resource, *NOT* as a
    replacement or alternative for a version selector.
    <jra>
    The difference is not between a version selector and a version, but the
    target of a version selector specified by its DAV:target property or
    through the Target-Selector header. These both specify a version.
    </jra>
    
       Version selectors
       are special resources, not bindings (too bad, but they aren't), so we
       can define the semantics of PROPFIND/PROPPATCH on a version selector to
       return both its properties and the properties of its target version.
    
    Or we can define that the dead properties of a version selector are
    identical to those of the current DAV:target version.  Achieves the
    desired result, without breaking the necessary distinction between
    a version selector and a version.
    <jra>
    No problem with the dead properties, its the live properties that are at
    issue. We should avoid defining the protocol so that clients have to use
    different marshaling for some properties than others.
    </jra>
    
       There should be no overlap, so no properties will be hidden.
       I think this is consistent with the definition of target in the core
       versioning section.
    
    Consistency with the definition of target is not the issue -- correct
    version selector and version semantics is.
    
    Cheers,
    Geoff
    
    
    
          From: Tim_Ellison@uk.ibm.com
    
          How do you refer to a version selector rather than the version it
       selects?
         (i.e. to PROPFIND/PROPPATCH it's properties)
    
    
       A version selector has a URL which is different from the URL
       of any particular version.  When you do a PROPFIND/PROPPATCH on a
       version selector URL, you operate on the properties of the version
       selector.  When you do a PROPFIND/PROPPATCH on a version URL,
       you operate on the properties of the version.
    
       Note though that all the dead properties of a version selector
       correspond (i.e. have the same value) as those of the version that
       is that target of that version selector.
    
       Further note that if you use a Target-Selector header with a
       PROPFIND/PROPPATCH request, you operate on the properties of
       the selected version, and *not* on the properties of the
       version selector.
    
    
          From: "Jim Amsden/Raleigh/IBM" <jamsden@us.ibm.com>
    
          You can't. PROPFIND returns the properties of both.
    
       PROPFIND returns the properties of whatever resource you
       applied it to.  In particular, the live properties of a version
       selector can be different from those of its target version.
       A while back, we modeled version selectors as a "redirector"
       that redirected methods to the version, but that was a
       good while ago, before we looked carefully at modeling
       versioned collections.
    
          Note that we can
         create version selectors with VERSION-CONTROL, but DELETE doesn't
         actually say you can delete them.
    
       You can use DELETE to delete a version selector.
    
          DELETE of a version is undefined.
    
       That is correct, but DELETE of a version selector is defined.
    
          DELETE on a version selector should just delete the version selector,
         but then we have a special case where the  version selector is
       accessed
         as a resource itself.
    
       A version selector is always accessed as a resource itself.
       A Target-Selector header can be used to redirect a request
       from a version selector to the specified version, but without
       a Target-Selector header, a method applied to a version selector
       URL is applied to the version selector resource.
    
          Remember the BIND/DELETE/UNBIND arguments? Geoff?
    
       Yes, we used to need this kind of argument when we modeled
       version selectors as redirectors, but we don't need them
       any more, now that we don't model them that way anymore.
    
       Cheers,
       Geoff
    
    
    
    
    
    
       --=_alternative 0072E64385256958_=
       Content-Type: text/html; charset="us-ascii"
    
    
       <br><font size=2 face="sans-serif">Geoff,</font>
       <br><font size=2 face="sans-serif">I think there are some problems with
    what you describe below. Any operation on a version selector should be
    redirected to the target version including PROPFIND/PROPPATCH regardless if
    a Target-Selector header was specified or not. The Target-Selector header
    is only there to override the DAV:target of the version selector. We don't
    want different semantics depending on how you specified you version.
    Version selectors are special resources, not bindings (too bad, but they
    aren't), so we can define the semantics of PROPFIND/PROPPATCH on a version
    selector to return both its properties and the properties of its target
    version. There should be no overlap, so no properties will be
    hidden.</font>
       <br>
       <br><font size=2 face="sans-serif">I think this is consistent with the
    definition of target in the core versioning section.</font>
       <br>
       <br>
       <br>
       <br><font size=2><tt>&nbsp; &nbsp;From: Tim_Ellison@uk.ibm.com<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;How do you refer to a version selector
    rather than the version it selects?<br>
        &nbsp; (i.e. to PROPFIND/PROPPATCH it's properties)<br>
       </tt></font>
       <br>
       <br><font size=2><tt>A version selector has a URL which is different
    from the URL<br>
       of any particular version. &nbsp;When you do a PROPFIND/PROPPATCH on
    a<br>
       version selector URL, you operate on the properties of the version<br>
       selector. &nbsp;When you do a PROPFIND/PROPPATCH on a version URL,<br>
       you operate on the properties of the version.<br>
       </tt></font>
       <br><font size=2><tt>Note though that all the dead properties of a
    version selector<br>
       correspond (i.e. have the same value) as those of the version that<br>
       is that target of that version selector.<br>
       </tt></font>
       <br><font size=2><tt>Further note that if you use a Target-Selector
    header with a<br>
       PROPFIND/PROPPATCH request, you operate on the properties of<br>
       the selected version, and *not* on the properties of the<br>
       version selector.<br>
       </tt></font>
       <br>
       <br><font size=2><tt>&nbsp; &nbsp;From: &quot;Jim
    Amsden/Raleigh/IBM&quot; &lt;jamsden@us.ibm.com&gt;<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;You can't. PROPFIND returns the
    properties of both.<br>
       </tt></font>
       <br><font size=2><tt>PROPFIND returns the properties of whatever
    resource you<br>
       applied it to. &nbsp;In particular, the live properties of a version<br>
       selector can be different from those of its target version.<br>
       A while back, we modeled version selectors as a
    &quot;redirector&quot;<br>
       that redirected methods to the version, but that was a<br>
       good while ago, before we looked carefully at modeling<br>
       versioned collections.<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;Note that we can<br>
        &nbsp; create version selectors with VERSION-CONTROL, but DELETE
    doesn't<br>
        &nbsp; actually say you can delete them.<br>
       </tt></font>
       <br><font size=2><tt>You can use DELETE to delete a version
    selector.<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;DELETE of a version is undefined.<br>
       </tt></font>
       <br><font size=2><tt>That is correct, but DELETE of a version selector
    is defined.<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;DELETE on a version selector should
    just delete the version selector,<br>
        &nbsp; but then we have a special case where the &nbsp;version selector
    is accessed<br>
        &nbsp; as a resource itself.<br>
       </tt></font>
       <br><font size=2><tt>A version selector is always accessed as a resource
    itself.<br>
       A Target-Selector header can be used to redirect a request<br>
       from a version selector to the specified version, but without<br>
       a Target-Selector header, a method applied to a version selector<br>
       URL is applied to the version selector resource.<br>
       </tt></font>
       <br><font size=2><tt>&nbsp; &nbsp;Remember the BIND/DELETE/UNBIND
    arguments? Geoff?<br>
       </tt></font>
       <br><font size=2><tt>Yes, we used to need this kind of argument when we
    modeled<br>
       version selectors as redirectors, but we don't need them<br>
       any more, now that we don't model them that way anymore.<br>
       </tt></font>
       <br><font size=2><tt>Cheers,<br>
       Geoff<br>
       </tt></font>
       <br>
       <br>
       <br>
       <br>
       --=_alternative 0072E64385256958_=--