RE: content type for WebDAV request/response bodies, was: [ACL] A ccess 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

Received on Sunday, 18 November 2001 13:45:28 UTC