Lisa Dusseault | 6 Apr 2003 22:08
Favicon

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
(Continue reading)

Julian Reschke | 7 Apr 2003 14:11
Picon
Picon

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.
(Continue reading)

Lisa Dusseault | 7 Apr 2003 19:40
Favicon

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
(Continue reading)

Julian Reschke | 7 Apr 2003 20:16
Picon
Picon

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: Monday, April 07, 2003 7:40 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: 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?

At the end. See:

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

> > > I assume that sub-collections are orderable as well? That  is, if I
have
> > > an ordered collection containing several sub-collections, I  assume I
(Continue reading)

Lisa Dusseault | 7 Apr 2003 20:52
Favicon

RE: More on ordered collections


OK, this answers a lot of my 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?
> 
> It must order it at the end. See above.

I think this is the wrong behavior.  A MOVE within a collection is
simply a rename.  A server ought at least to be able to preserve the
ordering if Office/Web Folders does a rename.  Otherwise this
unnecessarily disturbs the author's ordering.  If we don't say "a server
MUST retain the relative position of a member when it is moved within
the same ordered collection without an explicit Position header", then
it should at least be a SHOULD.

> > >  - 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.
> >
(Continue reading)

Julian Reschke | 7 Apr 2003 21:27
Picon
Picon

RE: More on ordered collections


> From: Lisa Dusseault [mailto:lisa <at> xythos.com]
> Sent: Monday, April 07, 2003 8:52 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: More on ordered collections
>
>
> OK, this answers a lot of my 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?
> >
> > It must order it at the end. See above.

OK, you got me there :-)

The default of "end-of-ordering" in the absence of the Position header is
specified for the case where a new collection member is *added*. A MOVE can
be seen both as

1) removing a binding and adding a new binding or
2) renaming a binding.

(Continue reading)

Ted Hardie | 7 Apr 2003 20:37

Re: More on ordered collections


Process question:  what is the ACL list, and why is conversation
on a decision to be made by the working group moving to it?
If this is a design team, pleae note the IESG's statement
on the work of design teams at:

http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt

Thanks for filling me in,
					regards,
							Ted Hardie

>
>>>  - 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.
>
> If you do that using a MOVE? I *really strongly* disagree. ACLs are
> properties of a resource, not of it's binding/URL. MOVEing a resource 
> MUST
> move it's ACL with it, overwriting the target resource's ACLs. Please 
(Continue reading)

Jim Whitehead | 8 Apr 2003 19:16

RE: More on ordered collections


The ACL list can be loosely viewed as a design team. I say loosely, since
design teams are normally small and closed, and this list is open and free
for all to subscribe. It emerged as a way to prevent the main DAV list from
being occasionally swamped by ACL discussion.

Operationally, actively working members of the DAV WG are subscribed to both
the main DAV list and the ACL list, and so the ACL list serves as a
convenient partitioning and filtering mechanism for ACL discussions.

Of course, all drafts discussed on the ACL list are brought to the main DAV
list for WG last call, and for official decisions on consensus. See for
example:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0313.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0088.html

- Jim

> Process question:  what is the ACL list, and why is conversation
> on a decision to be made by the working group moving to it?
> If this is a design team, pleae note the IESG's statement
> on the work of design teams at:
>
> http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt
>
> Thanks for filling me in,
> 					regards,
> 							Ted Hardie

(Continue reading)

Julian Reschke | 7 Apr 2003 20:47
Picon
Picon

RE: More on ordered collections


> From: w3c-dist-auth-request <at> w3.org
> [mailto:w3c-dist-auth-request <at> w3.org]On Behalf Of Ted Hardie
> Sent: Monday, April 07, 2003 8:38 PM
> To: Julian Reschke
> Cc: Lisa Dusseault; 'Webdav WG'
> Subject: Re: More on ordered collections
>
>
>
> Process question:  what is the ACL list, and why is conversation

See info at: <http://www.webdav.org/acl/>

> on a decision to be made by the working group moving to it?
> If this is a design team, pleae note the IESG's statement
> on the work of design teams at:
>
> http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt
>
> Thanks for filling me in,

I was suggesting to take the question to the ACL mailing list, because it
affects mainly the WebDAV ACL spec, not the ordering spec (which is
discussed here on the "generic" WebDAV mailing list) -- the WebDAV ACL
mailing list simply is a better place to resolve open issues regarding the
behaviour of ACLs upon COPY/MOVE.

Julian

(Continue reading)


Gmane