W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

Re: DAV:resourcetype

From: Tim Ellison <Tim_Ellison@uk.ibm.com>
Date: Fri, 22 Jun 2001 10:10:26 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <OF0DC18E04.ED1CBB79-ON80256A73.0031203A@portsmouth.uk.ibm.com>
"Jim Amsden" <jamsden@us.ibm.com> wrote:


> <jra>
> Now you're mixing in (static) type declaration with state
> (or dynamic type). That's OK, but we could draw the line
> on static typing in DAV:resourcetype, and let clients use
> other property values to indicate dynamic state. This is
> of course typical of any OO application.
> </jra>

I don't know what you mean by static and dynamic for a web resource.  There
is only dynamic.

> Now, tell me how is this different to DAV:supported-*-set?
> <jra>
> Just that supported-*-set doesn't deal with override.

Neither does adding tags to DAV:resourcetype.  If I state <DAV:collection/>
what does that mean for the semantics of GET, PUT, etc.?  I claim it has to
mean what is written in RFC2518 for a DAV:collection otherwise clients have
no hope.

> What if someone in the future decides to redefine the meaning
> of <DAV:workspace/>.  It would be a breaking change, and it
> is incumbant upon them not to do so.
> <jra>
> Yes, but not if they define a new subtype that responds to the
> same methods and has the same properties, but behaves differently.
> The protocol is still OK.
> </jra>

I strongly disagree.  If a 'subtype' does not honour the semantics of the
supertype then existing clients are screwed.

[Java digression]
If you try subclassing java.util.Hashtable and redefining the methods to
play tunes, you can still pass those instances to methods that expect a
hashtable; but I guarantee you that those clients will not work properly.
You have to honour the semantics of the superclass.

> <jra>
> ...
> The fact that we have subsections in the DeltaV spec indicating
> the effect on DAV methods indicates the new DeltaV resources
> have different behavior.

They have extended, compatible behaviour.  We don't (for example) say that
MOVE no longer moves the resource as described by RFC2518.

Received on Friday, 22 June 2001 06:08:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC