RE: DAV:modificationdate (was bindings-last-modified (was RE: DAV :getlastmodified of collections))

I would prefer a more general new property, e.g. DAV:modificationdate as
proposed by Julian some days ago in another thread (I added a few words
about *bindings* of a collection to Julian's wording): 

    "A proper way to address this may be to define a new optional property 
    (if we make it optional, we may be able to get it into RFC52518bis), 
    for instance:

    Name:        modificationdate 
    Namespace:   DAV: 
    Purpose:     Records the time and date the resource was modified. 
    Value:       date-time   
    Description: The creationdate property should be defined on all DAV 
            compliant resources.  If present, it contains a timestamp 
            of the moment when the resource was last modified (i.e., the 
            moment when content and/or properties last changed,
            or, when the bindings of a collection last changed).
            This property is live and protected. The Internet date-time
            format is defined in [RFC3339], see the ABNF in section 5.6. 
    COPY/MOVE behavior: This property value SHOULD be kept during a 
            MOVE operation, but is re-initialized when a resource is 
            created with a COPY. It should not be set in a remote COPY. 
    
    <!ELEMENT modificationdate (#PCDATA) >"

Probably, w.r.t. properties, we need to clarify whether:
1) changes to *all* properties ought to be taken into account for setting
the modification date,
or only
2) changes to the *dead* properties plus some selected live properties (e.g.
non-protected properties).

I would go for 2).

Regards,
Peter 

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]
> Sent: Monday, September 08, 2003 17:19
> To: w3c-dist-auth@w3c.org
> Subject: DAV:bindings-last-modified (was RE: DAV:getlastmodified of
> collections)
> 
> 
> 
> I believe that we have concluded that DAV:getlastmodified depends on
> what the server returns on a GET on a collection, and therefore is not
> something we can define (since what the server returns on a GET on a
> collection is not defined).  So what we are really talking about in
> this thread is a new property (which without much thought, I've named
> DAV:bindings-last-modified).
> 
> This raises the key question: what will the client be using this new
> property for.  I suggest it be used to keep the structure of a client
> tree display synchronized with the names and resources on the server,
> in which case the client doesn't care whether the version-controlled
> state changes, as long as the named tree of resources is still valid.
> 
> Cheers,
> Geoff
> 
> > > "Julian Reschke" <julian.reschke@gmx.de> wrote on 
> 09/05/2003 06:08:11 
> PM:
> > > > But then we're missing the case of VERSION-CONTROL on a 
> versionable 
> but not
> > > > yet version-controlled resource that lives inside a versioned 
> collection (in
> > > > which case I'd say the state of the parent collection *does* 
> change).
> 
> > > Geoffrey M Clemm
> > > I suggest we keep the semantics very simple, and say that 
> DAV:getlastmodified
> > > is changed only by adding a binding, removing a binding, 
> or changing a 
> binding
> > > to new resource.  Putting an existing resource under 
> version control 
> does
> > > none of these things, so it should not result in an update to
> > > DAV:getlastmodified.
> > >
> > > Note that in general the "version-controlled state" of a 
> collection 
> will be
> > > different from the "state" of a collection, i.e. adding 
> and removing a 
> binding
> > > to a non-version-controlled resource does not change the 
> version-controlled
> > > state of a collection, but does change the state of the 
> collection.
>  
> "Julian Reschke" <julian.reschke@gmx.de> wrote on 09/08/2003 
> 09:45:20 AM:
> > This seems to imply that the version-controlled state is 
> not a subset of 
> the
> > state, or more precisely, that you can modify the 
> version-controlled 
> state
> > without changing the state. This IMHO seems to be a weird 
> way to define 
> the
> > state of a collection.
> 
>