Rationale for DAV:if-unsupported?

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

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.

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

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

- Jim

Received on Wednesday, 1 November 2000 18:27:27 UTC