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

> From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Jim
> Whitehead
> Sent: Tuesday, November 20, 2001 2:10 AM
> To: acl@webdav.org; WebDAV
> Subject: RE: content type for WebDAV request/response bodies, was: [ACL]
> Access Control Protocol -07 submitted
>
>
> > 1) The RFC2518 DTD has an error in the keepalive element (at
> > least according to MSXML).
>
> OK -- how *should* this element be represented in DTD language?

I'm not DTD expert, but in the worst case it would have to be "ANY".

> > 2) Example 8.1.1 in RFC2518 (response) isn't wellformed.
>
> Which is the offending element. This looks OK to me.

~/dav-validation> saxon exmpl-8.1.1.f.2.xml ../identity.xslt
Error on line 17 column 26 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:DingALing
Error on line 17 column 26 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:DingALing
Error on line 17 column 32 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:Random
Error on line 17 column 32 of
file:/c:/reschke/dav-validation/exmpl-8.1.1.f.2.xml:
  Error reported by XML parser: undeclared name prefix in: R:Random
Error
  XML Parsing failed
Transformation failed: run-time errors were reported

> > 3) Several DTD validation errors were found:
> >
> > 3a) in ordering of lockdiscovery child elements,
> > 3b) in the examples in appendix C (which were supposed to fail).
> >
> > Question: so *do* we assume that child element ordering is relevant? In
> > which case, the examples in RFC2518 should be fixed.
>
> It was certainly my and Yaron's position that the ordering rules of XML
> didn't apply when sending XML across the wire. That is, the ordering rules
> make sense when you're doing markup of documents, but do not when you're
> sending a set of protocol elements where semantically the order of arrival
> is not meaningful. However, reading through RFC 2518, it appears we never
> explicitly stated this. It is certainly implied in the fact that we do not
> require validity, but only well formedness.  Well-formed XML does not
> necessarily adhere to the ordering given in a specific DTD.

You can't loosen the rules for XML validity (without stating them precisely
and possibly giving them a different term).

WebDAV messages can't be validated programatically, so well-formedness is
all we have.

We are having this discussion as I was trying to come up with a way how to
turn the (by definition) non-normative DTD fragments into something that is
actually usable (even if just for debugging).

I agree that in WebDAV, element ordering *shouln't* matter. If this is the
consensus, I'd try to rephrase my proposal so this is covered. In
particular, the transformation algorithm would have to re-order elements
(which requires some typing, but shouldn't be a problem).

Yes, this is getting messy. Other approaches would be:

- make sure that the specs work without the DTD fragments (I think deltav
does), or

- use a schema language that does what we need (I think XML Schema won't
work either because of the ordering aspect, but RELAX NG might do it).

Julian

Received on Tuesday, 20 November 2001 03:18:37 UTC