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: Monday, May 28, 2001 5:05 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: PROPFIND allprop with more properties (was AW: Resource
> class )
>
>
>    From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
>
>    > <propfind xmlns="DAV:">
>    >   <allprop>
>    >     <checked-in/><checked-out/><version-name/>
>    >   </allprop>
>    > </propfind>
>
>    This one won't interoperate with old servers, because <allprop> is
>    defined to be EMPTY (in RFC2518).
>
> Argh.  Julian is of course right (again :-).  Although I will point
> out (hopefully correctly, for a change :-), that 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).

> But either way (i.e. nesting the DAV:include inside of DAV:propfind,
> or nesting it inside of DAV:allprop) is fine with me.

OK, I'll put together a proposal.

>    > From: Stefan Eissing
>    > ...
>    > I find the arguments in RFC2518 Ch. 23.3 (esp. 23.3.2.2) very
>    > convincing.  Thus the most backward compatible solution is using
>    > include in its own namespace:
>    >
>    > <propfind xmlns="DAV:">
>    >   <allprop/>
>    >   <DV:include xmlns:DV="DAV:deltav">
>    >     <checked-in/><checked-out/><version-name/>
>    >   </DV:include>
>    > </propfind>
>    >
>    > where I don't specifically care what the namespace is (could also
>    > be "DAV:extended" or "DAV:addons-to-rfc2518"). If an implementor
>    > follows RFC2518, non-aware servers have to accept this message as
>    > a valid propfind/allprop (and indeed all I could test against
>    > do).
>
>    I can't see why putting it into the DAV: namespace would be a
>    problem.  Although I'd prefer to have other WebDAV related specs
>    (like ACL and deltaV) use their own namespaces, this one seems to
>    apply to all WebDAV servers, no matter whether any combination of
>    ACL and DeltaV is implemented...
>
> I agree with Julian that there is no reason to put the "include"
> element in its own namespace.  RFC 2518 requires a server to ignore
> any XML element it doesn't understand, irrespective of what namespace
> it appears in.  The example in 23.3.2.2 does show the extension in
> another namespace, but that is just an example.
>
> 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...

Julian

Received on Monday, 28 May 2001 16:29:40 UTC