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

Re: resourcetype (was: RE: Core versioning issues and nits)

From: James J. Hunt <jjh@allerton.de>
Date: Tue, 06 Feb 2001 12:44:00 +0000
Message-ID: <3A7FF190.C621C2A3@allerton.de>
To: Tim_Ellison@uk.ibm.com
CC: ietf-dav-versioning@w3.org
Tim_Ellison@uk.ibm.com wrote:

> I agree with Lisa.
> (other than the comment "somebody could set the 'DAV:checked-in' property
> to ANY value" because (1) just 'somebody' should not be using the DAV:
> namespace, especially without consideration of the current specs., (2)
> servers should enforce (1), and (3) servers that did have an opionion about
> DAV:checked-in would definitely disallow setting any value, so clients
> would fail very early.)
> Regards,
> Tim Ellison
> Java Technology Centre, MP146
> IBM UK Laboratory, Hursley Park, Winchester, UK.
> tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452
> "Lisa Dusseault" <lisa@xythos.com> on 2001-02-05 10:58:35 PM
> Please respond to lisa@xythos.com
> To:   "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>,
>       ietf-dav-versioning@w3.org
> cc:
> Subject:  RE: Core versioning issues and nits
> >
> >    I agree that determining type by the absence of properties is
> >    sub-optimal; I'd say it's not very reliable.
> >
> > How is it any less reliable than looking for a particular value
> > in a "resourcetype" property?
> A particular value on a particular property can be preserved even when
> the protocol changes (whether the protocol is changing as a result of
> sanctioned IETF activity or independent vendor activity).  Also, a
> particular value on a particular property is less likely to appear "by
> accident".
> In contrast, the absence of a property is less likely to be preserved
> when extending the protocol: somebody will come up with a new useful
> value for the property, and break clients that relied on that property
> being absent.  Or, on an non-versioning server like IIS 5.0 that
> supports dead properties, somebody could set the "DAV:checked-in"
> property to ANY value, and no matter what value it's set to, it risks
> breaking clients that look for that property.
> I'm not saying this is broke (particularly if the DAV:supported-methods
> comes back as a property).  It's just not as reliable as I would prefer.
> Lisa

Dear Colleagues,

I think that the spec. should explicitly reserve all names in the DAV
namespace.  Application properties should be limited to other namespaces.
That would avoid this problem.

Received on Tuesday, 6 February 2001 06:45:08 UTC

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