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

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, May 29, 2001 9:23 PM
> To: ietf-dav-versioning@w3.org
> Subject: 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

Yes, it is :-) That's why I tried to carefully phrase my last reply..

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

I'd say, if the request was

<allprop> <include>...</include> </allprop>

the result of "ignoring" would indeed be:

<allprop> </allprop>

However, if the request was

<allprop><include>...</include></allprop>

it would surely be

<allprop></allprop>, which for all practical purposes is the same as
<allprop/>.

> According to the XML standard, these are equivalent, so either one of
> these is fine.  There is an "interoperability" recommendation that

Not really -- the first variation contained a text node with whitespace, so
it wan't empty...

> 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

I agree that this statement needs to be removed.

> 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 :-)

I feel you're right.

How do we proceed?

I've done interoperabilty tests with "our" version of the include element
(with mod_dav, IIS and Sharepoint). Should I redo them using "your" format
before we proceed with one of them?

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

Sure. That's why I would like to see those moved out of deltaV (and into
RFC2518's successor).

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

Received on Tuesday, 29 May 2001 15:55:31 UTC