W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Rationale for DAV:if-unsupported?

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 2 Nov 2000 15:55:59 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B10D9F6B@SUS-MA1IT01>
To: "DeltaV (E-mail)" <ietf-dav-versioning@w3.org>
   From: "Jim Whitehead" <ejw@cse.ucsc.edu>

   So, I understand the surface rationale for the DAV:if-unsupported
attribute.
   There is a desire to ensure that, for some XML elements, DeltaV
   implementations MUST fail if they do not understand the element (when
   DAV:if-unsupported="error").
   What I don't understand are the specific use cases driving this feature.

Just for the record, you were the one that requested this feature
originally, but I'll take over its defense (:-).

   The example in Section 3.1.1 is uncompelling -- it seems quite reasonable
to
   mandate that every DeltaV server, whether Basic or Advanced, understand
the
   checkout XML element, or be judged non-compliant.  Thus, setting
   DAV:if-unsupported="error" on the checkout XML element is redundant.

This is here for extensibility.  We will undoubtebly be adding new
parameters to the various commands over time, and a server needs to
know if it is something it can ignore or not.

For example, suppose we wanted to add a DAV:keep-checked-out parameter
to the VERSION-CONTROL request?  A client could survive quite well if
this parameter were ignored (the user would just have to explicitly
check it out later), but some clients might be generating an automatic
sequence of requests, and wouldn't want to be surprised.

   Assuming there is a compelling use case, I have a few nits about this
   feature:

   * At present, it is specified as a double-negative (if this element is
not
   supported, then treat it as a non-success).  I'd rather see this
   reformulated in terms of positive logic, since I believe that's easier
for
   people to understand, and implement right.  So, I'd rename the attribute
   "must-understand", with values "true" and "false", with true meaning the
   interpretation fails if the implementation doesn't understand the
element,
   and false meaning the element can safely be ignored using the DAV ignore
   rule.

DAV:must-understand="T" is certainly fine, but DAV:must-understand="F"
looks rather weird (at first glance, it might look like you are requiring
that the server *not* understand the element :-).

DAV:if-unsupported="ignore" does not have this problem, and claiming
that if-unsupported="fail" is a double negative because you can
replace "fail" with "not succeed" is rather bogus, since with that
technique, you can make any statement into a double negative by
replacing both terms with the negations of their inverses.

But I don't care much, so I'll go ahead and make the change if nobody
else cares.  Note: I'll make it "must-support", since a server can
understand a feature but not support it, and it is the support that
the client cares about.

   * The text describing this attribute assumes that it would only be used
in
   client to server message traffic.  However, XML traffic flows in both
   directions in DeltaV, so I think it makes sense to discuss what the
client
   should do if it uncounters an "if-unsupported='error'" attribute.
Treating
   the result as a server-generated syntax error might be appropriate, or it
   might generally be OK for the client to use the DAV ignore rule.

I don't follow you.  What would a client ever do differently if
it encounters a DAV:must-support coming from the server?

   * The inheritance rule for DAV:if-unsupported could uncessarily limit the
   kind of XML processing that can be performed.  Some XML parsing
strategies
   simply use sophisticated string searches, and don't perform tree
traversals.
   Such an implementation would be slowed by the inheritance requirement.

OK, I'm happy to get rid of the inheritance requirement.

Cheers,
Geoff
Received on Thursday, 2 November 2000 15:56:42 GMT

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