RE: PROPFIND allprop with more properties (was AW: Resource class )

(Warning: detailed multi-spec language lawyering to follow :-)

   From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]

   > From:  Clemm, Geoff
   > ... you could nest the
   > DAV:include node inside the DAV:allprop, rather than inside the
   > DAV:propfind, i.e.
   >
   >  <propfind xmlns="DAV:">
   >   <allprop>
   >    <include>
   >     <checked-in/><checked-out/><version-name/>
   >    </include>
   >   </allprop>
   >  </propfind>

   Well, that would be invalid for the same reason (I think).

Now that's an interesting question.  According to section 14 of RFC
2518, a server that didn't understand the DAV:include element must
ignore it (and its children).  So the question then is, what does
"ignore" mean?  In particular, does the result of "ignoring" the
include element in:
 <allprop> <include>...</include> </allprop>
have to be:
 <allprop> </allprop>
or could it be:
 <allprop/>

According to the XML standard, these are equivalent, so either one of
these is fine.  There is an "interoperability" recommendation that
empty tags be used if and only if the DTD explicitly declares it to be
EMPTY, where interoperability is defined as:

"A non-binding recommendation included to increase the chances that
XML documents can be processed by the existing installed base of SGML
processors".

Since the chances of using an existing SGML processor to parse WebDAV
response messages is vanishingly small, the only sensible approach
would be for WebDAV to ignore this "non-binding recommendation".  For
some reason, Section 23.3.1 of RFC 2518 (incorrectly) states that "It
is a violation of the XML specification" to do otherwise.  Perhaps
JimW or some other 2518 author can explain the rationale behind this?

So in summary, nesting the <DAV:include> inside of the <DAV:allprop>
would be illegal only by a certain interpretation of "ignore",
combinded with the (incorrect) statements made by 23.3.1 about the use
of empty element tags.

(language-lawyering off :-)

   > Julian: Why would you prefer to have WebDAV extensions defined
   > through the IETF (such as DeltaV and ACL) use their own
   > namespaces?  There clearly is a reason to define non-IETF
   > standardized properties in their own namespace, but it is simpler
   > to just have all IETF WebDAV extensions use the DAV: namespace.

   Other to make it simpler to find out to which spec a "new" property
   belongs to? No. Right now we have the unfortunate situation that
   deltaV defines live properties in the DAV: namespace which could
   apply to base WebDAV as well -- so for an implementor it's not
   obvious where to find the definition.  Additionally, deltaV
   requires a change in the RFC2518-defined behaviour for <allprop>,
   which should be defined in the base WebDAV spec instead...

This assumes that the definition of a property will over time remain
in a single RFC.  I don't think this is likely.  In particular, there
are several properties currently defined by the deltav spec that over
time may well migrate into the "base WebDAV" protocol
(e.g. DAV:supported-live-property-set).  If so, the only thing you
will be able infer from the namespace of a property is that it was
"first defined" in RFC XYZ, but that is of neglible value.

So I believe putting all IETF standardized WebDAV properties into the
DAV: namespace is the best approach.  Save the other namespaces for
properties introduced by non-IETF standards (which therefore require
their own namespaces to avoid name clashes).

Cheers,
Geoff

Received on Tuesday, 29 May 2001 15:20:19 UTC