FW: [Moderator Action] WEBDAV and Message Properties; Specifically "Changed By" Value

Ordered collections and versioned collections

It seems from draft-ietf-webdav-ordering-protocol-07 that only
version-controlled resources are part of the ordering of
version-controlled collections (Section 9: "for compatibility with
RFC3253, only the ordering of version-controlled members needs to be
maintained")

Does that mean there's no way to order versioned and unversioned
resources together within a version-controlled collection?

Lisa

RE: Ordered collections and versioned collections

   From: Lisa Dusseault [mailto:lisa <at> xythos.com]

   It seems from draft-ietf-webdav-ordering-protocol-07 that only
   version-controlled resources are part of the ordering of
   version-controlled collections (Section 9: "for compatibility with
   RFC3253, only the ordering of version-controlled members needs to
   be maintained")

   Does that mean there's no way to order versioned and unversioned
   resources together within a version-controlled collection?

That is correct.  The issue is that when you UPDATE a
version-controlled collection with a new version, it can change the
set of version-controlled members, and there would not be a way to
define what the ordering of the existing non-version-controlled
members should be wrt the new version-controlled members.

Cheers,
Geoff

RE: Ordered collections and versioned collections

> From: w3c-dist-auth-request <at> w3.org
> [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, April 05, 2003 10:47 PM
> To: Webdav WG
> Subject: Ordered collections and versioned collections
>
>
>
>
> It seems from draft-ietf-webdav-ordering-protocol-07 that only
> version-controlled resources are part of the ordering of
> version-controlled collections (Section 9: "for compatibility with
> RFC3253, only the ordering of version-controlled members needs to be
> maintained")

The full context being:

"This specification considers both the ordering type (DAV:ordering-type
property) and the ordering of collection members to be part of the state of
a collection. Therefore both MUST be recorded upon CHECKIN or
VERSION-CONTROL, and both MUST be restored upon CHECKOUT, UNCHECKOUT or
UPDATE (where for compatibility with RFC3253, only the ordering of
version-controlled members needs to be maintained)."

> Does that mean there's no way to order versioned and unversioned
> resources together within a version-controlled collection?

Nope. It's supposed to mean that you *can* order both types of resources
within a versioned-controlled collection, but collection *versions* will
only keep ordering information for those members that were
version-controlled.

Do I need to rephrase the text to make this clearer?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

RE: Ordered collections and versioned collections

> From: w3c-dist-auth-request <at> w3.org
> [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 4:41 AM
> To: Webdav WG
> Subject: RE: Ordered collections and versioned collections
>
>
>
>    From: Lisa Dusseault [mailto:lisa <at> xythos.com]
>
>    It seems from draft-ietf-webdav-ordering-protocol-07 that only
>    version-controlled resources are part of the ordering of
>    version-controlled collections (Section 9: "for compatibility with
>    RFC3253, only the ordering of version-controlled members needs to
>    be maintained")
>
>    Does that mean there's no way to order versioned and unversioned
>    resources together within a version-controlled collection?
>
> That is correct.  The issue is that when you UPDATE a
> version-controlled collection with a new version, it can change the
> set of version-controlled members, and there would not be a way to
> define what the ordering of the existing non-version-controlled
> members should be wrt the new version-controlled members.

Wait-a-minute 

For instance, we can define that the UPDATE operation does not define the
ordering of those members (that is, the server (a) may insert them in
arbitrary places or (b) must insert them at the end). Currently the
postcondition is:

"(DAV:update-version-controlled-collection-members-ordered): If the request
modified the DAV:checked-in version of a version-controlled collection and
the DAV:ordering-type for the checked-in version is not unordered
("DAV:unordered"), the version-controlled members MUST be ordered according
to the checked-in version's DAV:version-controlled-binding-set property."

How about adding:

"Members that are not version-controlled MUST be moved to the end of the
ordering (in no particular order)."

This behaviour would be consistent with section 6.1 (setting the position
when no ordering information was specified).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

RE: Ordered collections and versioned collections

   From: Julian Reschke [mailto:julian.reschke <at> gmx.de]

   > From:  Clemm, Geoff
   >
   >    From: Lisa Dusseault [mailto:lisa <at> xythos.com]
   >
   >    It seems from draft-ietf-webdav-ordering-protocol-07 that only
   >    version-controlled resources are part of the ordering of
   >    version-controlled collections (Section 9: "for compatibility with
   >    RFC3253, only the ordering of version-controlled members needs to
   >    be maintained")
   >
   >    Does that mean there's no way to order versioned and unversioned
   >    resources together within a version-controlled collection?
   >
   > That is correct.  The issue is that when you UPDATE a
   > version-controlled collection with a new version, it can change the
   > set of version-controlled members, and there would not be a way to
   > define what the ordering of the existing non-version-controlled
   > members should be wrt the new version-controlled members.

   For instance, we can define that the UPDATE operation does not
   define the ordering of those members (that is, the server (a) may
   insert them in arbitrary places or (b) must insert them at the
   end). Currently the postcondition is:

   "(DAV:update-version-controlled-collection-members-ordered): If the
   request modified the DAV:checked-in version of a version-controlled
   collection and the DAV:ordering-type for the checked-in version is
   not unordered ("DAV:unordered"), the version-controlled members
   MUST be ordered according to the checked-in version's
   DAV:version-controlled-binding-set property."

   How about adding:

   "Members that are not version-controlled MUST be moved to the end of the
   ordering (in no particular order)."

   This behaviour would be consistent with section 6.1 (setting the position
   when no ordering information was specified).

That would be fine with me, or just saying that the order of the
non-version-controlled members is server-defined following the UPDATE.

Cheers,
Geoff

More on ordered collections

Is the position of a newly-defined resource in an ordered collection
treated the same way by all servers?   It would be nice to be specific
about how new resources are added to an ordered collection.

I assume that sub-collections are orderable as well? That is, if I have
an ordered collection containing several sub-collections, I assume I can
define an ordering that includes all sub-collections along with all
other children.  I believe this is already clear through the term
"member" even though none of the examples show a sub-collection.

Other questions
 - If I MOVE a resource within the same collection, must the server
preserve its ordering position wrt other resources?
 - If I COPY a resource within the same collection, where is the new
resource placed in the ordering -- next to the old resource (closely
preserving its ordering semantics), or at the end, or arbitrary?
 - If I MOVE or COPY a resource into a collection, overwriting a
resource that has an ordering position, is that ordering position (of
the destination) preserved?
 - If I DELETE a resource, must the server preserve the ordering other
than that deleted resource?  Section 4 could be more explicit that if
resource C is after B is after A, then the deletion of B means that C
must be after A rather than destroying the ordering relationship.  This
is worth making explicit because server implementors must either
maintain their orderings in a format that is irrelevant to what
resources exist (absolute), or relative orderings must be fixed up when
a resource is deleted.

Note that the answers to the MOVE/COPY questions are particularly
important if WebDAV clients do "Safe-save" operations -- e.g. a client
that PUTs an new resource then uses COPY to overwrite the existing
resource after finding that the PUT worked.  There are many other
variations in safe-save algorithms, some using MOVE.

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request <at> w3.org 
> [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 12:17 PM
> To: Webdav WG
> Subject: RE: Ordered collections and versioned collections
> 
> 
> 
>    From: Julian Reschke [mailto:julian.reschke <at> gmx.de]
> 
>    > From:  Clemm, Geoff
>    >
>    >    From: Lisa Dusseault [mailto:lisa <at> xythos.com]
>    >
>    >    It seems from draft-ietf-webdav-ordering-protocol-07 that only
>    >    version-controlled resources are part of the ordering of
>    >    version-controlled collections (Section 9: "for 
> compatibility with
>    >    RFC3253, only the ordering of version-controlled 
> members needs to
>    >    be maintained")
>    >
>    >    Does that mean there's no way to order versioned and 
> unversioned
>    >    resources together within a version-controlled collection?
>    >
>    > That is correct.  The issue is that when you UPDATE a
>    > version-controlled collection with a new version, it can 
> change the
>    > set of version-controlled members, and there would not 
> be a way to
>    > define what the ordering of the existing non-version-controlled
>    > members should be wrt the new version-controlled members.
> 
>    For instance, we can define that the UPDATE operation does not
>    define the ordering of those members (that is, the server (a) may
>    insert them in arbitrary places or (b) must insert them at the
>    end). Currently the postcondition is:
> 
>    "(DAV:update-version-controlled-collection-members-ordered): If the
>    request modified the DAV:checked-in version of a version-controlled
>    collection and the DAV:ordering-type for the checked-in version is
>    not unordered ("DAV:unordered"), the version-controlled members
>    MUST be ordered according to the checked-in version's
>    DAV:version-controlled-binding-set property."
> 
>    How about adding:
> 
>    "Members that are not version-controlled MUST be moved to 
> the end of the
>    ordering (in no particular order)."
> 
>    This behaviour would be consistent with section 6.1 
> (setting the position
>    when no ordering information was specified).
> 
> That would be fine with me, or just saying that the order of the
> non-version-controlled members is server-defined following the UPDATE.
> 
> Cheers,
> Geoff
> 
> 

RE: More on ordered collections

> From: w3c-dist-auth-request <at> w3.org
> [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Lisa Dusseault
> Sent: Sunday, April 06, 2003 10:09 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: More on ordered collections
>
>
>
> Is the position of a newly-defined resource in an ordered collection
> treated the same way by all servers?   It would be nice to be specific
> about how new resources are added to an ordered collection.

Yes.

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

> I assume that sub-collections are orderable as well? That is, if I have
> an ordered collection containing several sub-collections, I assume I can
> define an ordering that includes all sub-collections along with all

Nope. Ordering is a property of the internal (!) members of a collection, so
it doesn't automatically affect child collections:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#rfc.section.4.p.4>

> other children.  I believe this is already clear through the term
> "member" even though none of the examples show a sub-collection.
>
> Other questions
>  - If I MOVE a resource within the same collection, must the server
> preserve its ordering position wrt other resources?

That depends on the Position header:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

>  - If I COPY a resource within the same collection, where is the new
> resource placed in the ordering -- next to the old resource (closely
> preserving its ordering semantics), or at the end, or arbitrary?

Same:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

>  - If I MOVE or COPY a resource into a collection, overwriting a
> resource that has an ordering position, is that ordering position (of
> the destination) preserved?

Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE the
target.

>  - If I DELETE a resource, must the server preserve the ordering other
> than that deleted resource?  Section 4 could be more explicit that if
> resource C is after B is after A, then the deletion of B means that C
> must be after A rather than destroying the ordering relationship.  This
> is worth making explicit because server implementors must either
> maintain their orderings in a format that is irrelevant to what
> resources exist (absolute), or relative orderings must be fixed up when
> a resource is deleted.

I think this follows from the definition of "ordering" (repeatability of
PROPFIND result element ordering).

> Note that the answers to the MOVE/COPY questions are particularly
> important if WebDAV clients do "Safe-save" operations -- e.g. a client
> that PUTs an new resource then uses COPY to overwrite the existing
> resource after finding that the PUT worked.  There are many other
> variations in safe-save algorithms, some using MOVE.

Those servers will need to set the Position header accordingly if they want
the resulting resource to be in the "original" position.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

RE: Ordered collections and versioned collections

> From: w3c-dist-auth-request <at> w3.org
> [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 9:17 PM
> To: Webdav WG
> Subject: RE: Ordered collections and versioned collections
>
>
> ...
>
>    How about adding:
>
>    "Members that are not version-controlled MUST be moved to the
> end of the
>    ordering (in no particular order)."
>
>    This behaviour would be consistent with section 6.1 (setting
> the position
>    when no ordering information was specified).
>
> That would be fine with me, or just saying that the order of the
> non-version-controlled members is server-defined following the UPDATE.

Agreed (resolved as "server-defined"):

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.issue.9.4-UPDATE-non-version-controlled-members>

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

RE: More on ordered collections

Sorry, I must not have been sufficiently clear in my questions.  I'm
mostly discussing operations without the Position header -- operations
with clients that aren't aware of ordering.

> > Is the position of a newly-defined resource in an ordered collection
> > treated the same way by all servers?   It would be nice to 
> be specific
> > about how new resources are added to an ordered collection.

So this meant, how are resources added to a client-ordered collection
when the Position header is missing? Must servers add them to the end of
the ordering or can they be put at the beginning or anywhere?

> > I assume that sub-collections are orderable as well? That 
> is, if I have
> > an ordered collection containing several sub-collections, I 
> assume I can
> > define an ordering that includes all sub-collections along with all
> 
> Nope. Ordering is a property of the internal (!) members of a 
> collection, so
> it doesn't automatically affect child collections:

Again I was unclear.  I meant direct sub-collections, or collections
which are direct children of the ordered collection. These are ordered
together with regular child resources, correct?  There are no examples
of this but I believe this is what the spec says.

> > Other questions
> >  - If I MOVE a resource within the same collection, must the server
> > preserve its ordering position wrt other resources?
> 
> That depends on the Position header:

What happens if the Position header is not present?  Must servers
preserve the ordering or lose it?

> >  - If I COPY a resource within the same collection, where is the new
> > resource placed in the ordering -- next to the old resource (closely
> > preserving its ordering semantics), or at the end, or arbitrary?

And here, what happens if the COPY method has no Position header?

>  - If I MOVE or COPY a resource into a collection, overwriting a
> resource that has an ordering position, is that ordering position (of
> the destination) preserved?
> Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE
the
> target.

No, I disagree with this.  Overwriting a regular resource does not reset
all the live properties.  For example, it would be pretty disastrous for
the ACL property to be reset every time a resource is overwritten.
Besides, the ordering is a property of the parent, not the resource
being overwritten.  I would expect that ordering would be preserved, but
the spec ought to say one way or another.

> >  - If I DELETE a resource, must the server preserve the ordering
other
> > than that deleted resource?  Section 4 could be more explicit that
if
> > resource C is after B is after A, then the deletion of B means that
C
> > must be after A rather than destroying the ordering relationship.
This
> > is worth making explicit because server implementors must either
> > maintain their orderings in a format that is irrelevant to what
> > resources exist (absolute), or relative orderings must be fixed up
when
> > a resource is deleted.

> I think this follows from the definition of "ordering" (repeatability
of
> PROPFIND result element ordering).

Then why not make it explicit in the specification?

> > Note that the answers to the MOVE/COPY questions are particularly
> > important if WebDAV clients do "Safe-save" operations -- e.g. a
client
> > that PUTs an new resource then uses COPY to overwrite the existing
> > resource after finding that the PUT worked.  There are many other
> > variations in safe-save algorithms, some using MOVE.

> Those servers will need to set the Position header accordingly if they
want
> the resulting resource to be in the "original" position.

It is not the servers doing "safe save" operation, it's the clients, and
these may be clients that are unaware of ordering or choose not to set
the Position header.

It's important to consider how a server with an ordered collection
interacts with ordinary clients (ones that do not use the Position
header). Otherwise, an author that tries to keep their collection
ordered may frequently find the ordering  unecessarily "messed up" after
resources are added, deleted, renamed, or overwritten by non-ordering
client software (e.g. Office).

Lisa