RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

So I think we're real close here. Since we agree that there *may* be 
circumstances where new DAV:resourcetypes will need to be introduced 
(otherwise its a pretty useless property), then any issues with current 
servers that don't parse DAV:resourcetype properly would have to be 
addressed anyway. Given solutions to that problem, we are then faced with 
an opportunity to describe some of the more interesting static 
characteristics of the new DeltaV resources in a DAV:resourcetype as a 
convenience to client writers so they don't have to know the methods and 
properties supported by a particular type to know the type. This is of 
course not required, but since it is 1) more convenient, 2) standard OO 
practice, 3) established DAV practice, 4) solves any potential subtype 
override ambiguity problem, 5) is already (partially) in the DeltaV spec, 
and 6) fits well with our use of resource type names in the spec, it seems 
like a reasonable thing to conisder.

I like Tim's approach of including the supertype tags in the resource type 
with the subtype name first. This shouldn't break any client that follows 
the RFC2518 convention of ignoring unknown XML tags, provides all the 
static type information needed, and makes it very easy for clients to 
check for the type they are interested in by simply using 
getAllElementsByTagName() on the DAV:resourcetype element. Clients that 
can't handle this are not following the DAV spec and should probably be 
fixed rather than forcing the protocol to work around them.




"Clemm, Geoff" <gclemm@rational.com>
Sent by: ietf-dav-versioning-request@w3.org
06/21/2001 02:05 PM

 
        To:     ietf-dav-versioning@w3.org
        cc: 
        Subject:        RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline 
resource type values

 

For those (likely very few) new resource types that have exactly
the same properties and methods as an existing resource type, you would
be free to add an additional value to the DAV:resourcetype property.
But since none of the resources introduced by the versioning protocol
have this characteristic (i.e. they all have a set of new properties
or methods that they support), we needn't add new resource type values
in the DeltaV protocol.

Cheers,
Geoff 


-----Original Message-----
From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: Thursday, June 21, 2001 10:16 AM
To: ietf-dav-versioning@w3.org
Subject: RE: Removing the DAV:activity and DAV:version-history and
DAV:bas eline resource type values


I agree with Geoff that *most* new resource types do result in at least 
one new method and/or property. But this is fundamentally a poor thing to 
depend on as we know there can be (and therefore probably will be) 
subtypes that don't add new methods or properties, but only override 
behavior of their superclass. By not resolving the resource type issue to 
support such situations, we may be just putting the problem off in such a 
way that it will need to be solved in some very different manner by some 
future protocol extension. This is what keeps nagging at me.

Received on Thursday, 21 June 2001 14:32:46 UTC