notes of discussion of requirements for Advanced Collection Functionality at IETF WebDAV meeting Apr 2

On Thursday, April 2, I presented the requirements for advanced
collection functionality at the IETF WebDAV working group meeting.
These are my notes from the discussion.  

For the most part the notes
are tied to each numbered requirement.  Three questions that came up
not related to any specific requirement.

1) Can one have a reference to a reference?

[I would say yes.]

2) Are circular references possible?  

[I would say yes, and there is no requirement to prevent or even
detect them.]

3) Can a reference have more than one target (e.g. in content negotiation)

[I don't understand this.]

3.1.1 The same resource may be referenced by referential members of
multiple collections.

Agreed.

3.1.2 The same resource may be referenced by more than one referential
member of the same collection.

Agreed.

3.1.3 It is possible for the same resource to be an internal member of
a collection and also to be referenced by one or more referential
members of that same collection.

Agreed.

3.1.4 Operations on a referential member do not affect the resource it
references.

Agreed.

One suggested new requirement:

N.1 Operations on a target do not affect the reference(s)

I do not recall that we got concensus on this.

3.1.5 For any referential member of a collection, it is possible to
obtain the URI of the resource it references.  allows client to affect
target

Agreed.

3.1.6 It is possible to add a referential member to a collection.

Agreed.

3.1.7 It is possible to remove a referential member from a collection.

Agreed.

3.1.8 It is possible for a referential member of a collection to carry its
own properties, distinct from those of the resource it refers to.
e.g. "who added"

Agreed.

3.1.9 A referential member of a collection also inherits the
properties of the resource it refers to.

There was wide opposition to this, on the following grounds:

 1. Assuming that the properties are copied when the reference is
 created, it is unclear what access rights to use when doing the
 PROPFIND.

 2. After the properties are copied, the owner of the target resource
 no longer has means to control access on the properties.

 3. ACAP has had problems with 'inheritance'

 4. Referential members are like symbolic links.  But symbolic links
 do not in general have the 'properties' of their target.  Their
 owner, size, and date modified all differ.

In addition:

 4. If the properties are copied, they could be become out of date afterwards.

3.1.10 A listing of the members of a collection shows both the
internal members and the referential members.

Agreed.

3.1.11 Servers are encouraged to maintain referential integrity for
referential members as far as possible, but are not required to do so.

No agreement.  One objection is that "should" is too weak to be
useful. Some applications really care whether referential integrity
will be maintained.  For example, if I make a link to a resource
instead of copying it, I will be upset if the target is deleted.  I
would prefer to make a link that the server will PROMISE to protect
from deletion (perhaps using a 'reference counting' type scheme.)  So
the following were suggested as requirements.

N.2 It is possible to request creation of a referential member that
the server will guarentee to have referentially integrity.

The protocol might include a header that requested the server for
create the reference only if it could guarentee the integrity, and
otherwise fail. or it might return a description of what was created,
as for example the lockinfo returned by the LOCK method in DAV.

My note show we agreed on this new requirements.

N.3 It is possible to discover whether or not a referential member has such
'integrity protection'.

Proposed, but no agreement reached.  Needs discussion.

N.4 Is is possible to discover whether a resource is the target of
such a 'protected referential member'.

Proposed, but no agreement reached.  Needs discussion.

3.1.12 For any member of a collection, it is possible to discover
whether it is an internal or a referential member.

Agreed.

12. Requirements for Ordered Collections

3.2.1 The ordering mechanism is sufficiently standardized that
different applications and servers can operate on the same ordering
without private agreement.

Agreed, with change in wording: "Ordering is sufficiently
standardized..."

Basically, some folks were leery of the word 'mechanism'.

3.2.2 The semantics of an ordering are discoverable.

Agreed, but only after much discussion.  Some folks asks for a
definition of 'ordering semantics'. 

3.2.3 When a client requests a listing of the members of a collection,
it can specify the ordering to be applied, and the server will apply
that ordering to its response.

Agreed, with the addition that "The server may decline to support the
requested ordering".

3.2.4 It is possible to order the members of a collection in an
arbitrary way, not necessarily based on property values.

Agreed with the word 'arbitrary' changed to 'client-specified'.  One
way we got into trouble here is that since the ordering might well be
stored in a property, it's hard to think of an ordering that is NOT
based on a property value.  Also, there was much sentiment that DASL
should support sorting on property values, and that orderings based on
property values alone should be left to DASL and not addressed here.

3.2.5 Internal and referential members may by intermixed in the same ordering.

Agreed.

3.2.6 It is possible to impose multiple orderings on the same collection.

No agreement.  No one at the meeting was able to propose a scenario
that actually requires more than one ordering.  The scenario in the
requirements document was discredited, on the claim that the two
instructors should instead each create their own collections, using
referential members, and impose the ordering they wished.

3.2.7 An ordering is not required to contain all members of the collection.

No agreement, for the same reasons.

3.2.8 A collection member may belong to the same ordering more than once.

No agreement, same reasons.

3.2.9 It is possible to modify an existing ordering efficiently.

No agreement.  I can't really understand why, since this seems like a
'motherhood' statement.

We did not have time to discuss any of the "Issues" from the
req. draft.

Received on Friday, 3 April 1998 19:33:59 UTC