Re: DAV:resourcetype

I think we've beaten this one to death, but I'll make just a few more 
points.

- DeltaV resources do have static (meta) data, and dynamic state. Which is 
which is a matter of design. Type names are just a label for the meta-data 
which is generally used to describe a range of potential states.

- Yes, stating a resource type does require the servers to implement the 
semantics of that type. Just like it means they have to implement 
supported-*. No difference here. If we define DAV:resourcetypes, this will 
not give servers the ability to return these types but not implement the 
required properties, methods, and semantics.

- But here's the difference. In cases where new subtypes are introduced 
that don't add methods or properties, resource type is not redundant, but 
rather can be used to distinguish that subtype where the interface alone 
could not. This is extremely common in OO applications. The fact that we 
don't have many instances where it is the case now in 
WebDAV/DeltaV/DASL/ACL is fortunate, but might not be permanent.

- Of course a subtype could override a supertype method and do anything it 
wanted. If the behavior is completely inconsistent with the supertype, the 
marketplace will likely treat the 'feature' accordingly. However, there 
are many degrees of compatible behavior. Its difficult to predict which 
ones clients might be interested in distinguishing. 

Its hard to get a sense of where we are on this issue. However, if I were 
to attempt to summarize:

- The working group is pretty well split on defining DAV:resourcetypes for 
DeltaV

- Simply defining new resource types isn't enough, we need to be able to 
extend existing resource types to show generalization hierarchies.

- Some current servers will likely break if DAV:resourcetype is extended.

- The ACL spec has also proposed such extensions

- DeltaV at this time can indicate type through client introspection of 
supported properties and methods. Any new resource types would only serve 
to (redundantly) summarize this information.

- Using additional DAV:resourcetypes to (potentially redundantly) indicate 
type might simplify client implementations eliminating the need for 
clients to get and process supported properties and methods, and does 
allow the introduction of new distinguishable (sub) types when there are 
no new properties or methods if this ever became the case.

Where do I stand? Well, I'd prefer to keep the resource types because I 
think its simpler and more flexible (although we may never need the 
additional flexibility). But I can see how using supported properties and 
methods can work, and I don't think its necessarily worth holding the spec 
up at this time to introduce something else. Since the ACL spec also 
introduces the DAV:resourcetype extension problem, and the new DeltaV 
resource types are already in the spec that went through last call and is 
in the hands of the area directors, maybe the solution is to do nothing 
and leave the spec the way it is. We'd need to add support for 
generalization hierarchies though or down-level clients won't be able to 
do anything with DeltaV extensions to collection.






"Tim Ellison" <Tim_Ellison@uk.ibm.com>
Sent by: ietf-dav-versioning-request@w3.org
06/22/2001 05:10 AM

 
        To:     ietf-dav-versioning@w3.org
        cc: 
        Subject:        Re: DAV:resourcetype

 

"Jim Amsden" <jamsden@us.ibm.com> wrote:

[snip]

> <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.

Tim

Received on Friday, 22 June 2001 09:58:02 UTC