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.

Sincerely,
James
Received on Tuesday, 6 February 2001 06:45:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT