W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2001

RE: content type for WebDAV request/response bodies, was: [ACL] Access Control Protocol -07 submitted

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 18 Nov 2001 20:01:14 +0100
To: "Clemm, Geoff" <gclemm@rational.com>, <acl@webdav.org>, "WebDAV" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCCEMGDHAA.julian.reschke@gmx.de>
Correct.

This basically means that independant extensions of RFC2518 (say deltaV and
ACL) would have to define a common DTD to make things work. As long as this
is the case, the proposed validation mechanism should continue to work.

As long as ACL uses DTD fragments as "normative", I think we still need to
*properly* define what this actually means. I've seen clients freak out on
perfectly "valid" server responses, just because the authors decided that
they can "validate" against the WebDAV DTD. So this really needs to be
sorted out.

Julian


> -----Original Message-----
> From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
> Clemm, Geoff
> Sent: Sunday, November 18, 2001 7:44 PM
> To: acl@webdav.org; WebDAV
> Subject: RE: content type for WebDAV request/response bodies, was: [ACL]
> Access Control Protocol -07 submitted
>
>
> To allow for extensiblity, the DeltaV protocol leaves the ordering
> of the children of top-level protocol elements undefined.
> In particular, instead of specifying a DTD, a statement of the
> form "at most one of the following nodes can appear as a child"
> is used.
>
> This is motivated by the observation that under extension, the
> order of the children will always be at most partially constrained.
> In particular, suppose an element, A, was defined to have children
> B and C.  Now suppose there are two independent extensions,
> extension-X and extension-Y, that add new children to A.
> In particular, extension-X adds children D and E, and extenstion-Y
> adds children F and G.  Even if extension-X requires the ordering
> to be B,D,E,C and extension-Y requires the ordering to be B,F,G,C,
> a client that wants to handle both extensions cannot count on a fixed
> order for the children of A (e.g. B,D,E,F,G,C and B,D,F,E,G,C are
> two of the many possibilities).
>
> So I would propose that we explicitly state that the order of
> different types of child elements for top level WebDAV protocol
> elements is undefined.
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>
> Question: so *do* we assume that child element ordering is relevant? In
> which case, the examples in RFC2518 should be fixed.
>
> Julian
>
> _______________________________________________
> acl mailing list
> acl@webdav.org
> http://mailman.webdav.org/mailman/listinfo/acl
>
Received on Sunday, 18 November 2001 14:01:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT