W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1998

RE: Comments on 06 spec

From: Dylan Barrell <dbarrell@opentext.ch>
Date: Fri, 23 Jan 1998 10:35:37 +0100
Message-ID: <01BD27EA.A570B720@cassius.opentext.ch>
To: "'Judith Slein'" <slein@wrc.xerox.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>

[Dylan Barrell]  Comments Below

-----Original Message-----
From:	Judith Slein [SMTP:slein@wrc.xerox.com]
Sent:	Thursday, January 22, 1998 11:00 PM
To:	w3c-dist-auth@w3.org
Subject:	Comments on 06 spec

3. Semantics of external members

There are several points in the specification where I think the semantics
of external collection members is mistaken.  I think that the reason for
all of the anomalies is that you have decided to implement external members
as a property of the collection resource.  This implementation choice does
not force us to have the mistaken semantics, but it makes it more difficult
to get the semantics right.  I would argue that the semantics should drive
the implementation (and in fact we don't have to tell servers how to
implement external members at all).  So here are the problems:

Getting a listing of the members of a collection should result in a list
that includes both internal and external members, but according to 7.1 the
list will include internal members only.

A Depth = 0 COPY operation should not copy any members, internal or
external.  The new collection should not have any members. But according to
section 7.10.3, the new collection will have external members copied from
the old collection. 

The Depth header should define the behavior of a method for both internal
and external children, but according to 8.3 it affects only the behavior
for internal children.

[Dylan Barrell]  I Agree absolutely with Judith. The external memebers should not differ from internal members in anything other than a property defining whether they are external or internal. The content of the external member should then simply be the URI to the external reference.

This would result in a much cleaner implementation.

Received on Friday, 23 January 1998 04:33:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:12 UTC