RE: Syntax Issues

Juergen Reuter writes:
> While trying to implement a WebDAV/DeltaV based C/S application,
> some parsing related questions arose that I would like to have
> clarified, if possible.  In the mailing archive with recent postings
> of this list, I did not find any related topic, but I may have
> overseen some posting and would also be grateful for any reference.
>
> N.B.: [WebDAV] means RFC 2518, [XML] REC-xml-19980210,
> [Namespaces] REC-xml-names-19990114, and [HTTP] RFC 2068.
>
> 1. [WebDAV] section 23.1 (appendix 1), and 12.12.1:
>    As far as I understand [XML], the declaration
>    <!ELEMENT keepalive (#PCDATA | href+) >
>    is not a valid xml element declaration.  The use of both,
>    #PCDATA and children content href implies a mixed content
>    declaration.  For mixed content, [XML] section 3.2.2 defines
>    [51] Mixed ::= '(' S? '#PCDATA' (S? '|' S? Name)* S? ')*'
>                   | '(' S? '#PCDATA' S? ')'.
>    Hence, element keepalive may be declared as
>    <!ELEMENT keepalive (#PCDATA | href)* >
>    which is a more general form and might need to be further
>    restricted to its originally intended syntax on the semantic
>    level of the specification.
>
>    Alternatively, one could specify
>    <!ELEMENT keepalive (all | href+) >
>    <!ELEMENT all EMPTY>
>    where element all would effectively replace the '"*"'
>    PCDATA of the keepalive element.

Well, actually this one was caught on July 6, by Ashish Agrawal,
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0004.html

It is also listed in the RFC 2518 issues list:
http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

But, thanks for suggesting some alternate ways to rewrite the specification
of this element!


> 2. At a first look, [WebDAV] section 23.1 seems to present the
>    syntax in the style of a document type declaration as specified
>    in [XML] section 2.8, rule [28] (doctypedecl definition).
>    If this is intended, "the Name in the document type declaration
>    must match the element type of the root element" (cited from
>    [XML] validity constraint: root element type).  Effectively,
>    this would mean, that there must be an element named webdav-1.0
>    which serves as root element.  However, I can not find an element
>    declaration of the form <!ELEMENT webdav-1.0 ... >.  Instead,
>    the examples in [WebDAV] seem to use elements propfind,
>    multistatus, propertyupdate, propertybehaviour, lockinfo and prop
>    as varying root elements.  Hence, could an additional element
>    declaration such as
>    <!ELEMENT webdav-1.0 (propfind | multistatus |
>    propertyupdate | propertybehaviour | lockinfo | prop) >
>    solve this problem?

WebDAV applications are only required to send sequences of well formed XML
back and forth, and are not required to adhere to XML validity rules.  So,
while you're correct that we don't have a top-level container object, this
isn't a problem because we don't require validity.


> 3. The xml code in the examples in chapter 8 of [WebDAV] should, if I
>    understand right, be compliant with the syntax specified in
>    appendix 1.  Section 2.8 of [XML] says:
>    "An XML document is valid if it has an associated document type
>    declaration and if the document complies with the constraints
>    expressed in it."
>    Without supplying a DTD, the document can only be checked for
>    well-formedness, which does not seem to help very much for
>    real-life applications.  Hence, I would expect the xml code of
>    the examples in chapter 8 of [WebDAV] to begin as follows or
>    the like:
>    <?xml version="1.0" encoding="utf-8" ?>
>    <!DOCTYPE webdav-1.0 PUBLIC "-//W3C/DTD webdav-1.0//EN"
>    "http://www.w3.org/TR/1999/webdav-1.0.xml">
>    According to the root element issue (see above), I would expect then
>    <webdav-1.0>
>    followed by the lines as supplied in the examples in chapter 8,
>    and then followed by
>    </webdav-1.0>
>    which terminates the xml code.

See, there's that pesky validity acting up again.  While validity is useful
for sending documents around, where those documents can have widely varying
DTDs, in the WebDAV protocol, both ends of the protocol better know both the
syntax and semantics of the protocol, otherwise there will be no
interoperation. Since there is a finite set of XML elements used within
WebDAV, and since both ends of the protocol know them, and the rules for
combining them, doing strict XML validity checking doesn't add much.  On the
other hand, DAV clients and servers are required to make sure that XML
elements are nested correctly, and the nesting rules are given
prescriptively in the XML DTD language.  So, while DAV doesn't require XML
validity, it does require elements to be correctly nested.  By not requiring
validity, we can ignore the parts of XML that don't make sense in a protocol
setting like DAV, while keeping those parts that are useful (like nesting
hierarchies).

>
> 4. The response in the example in section 8.1.1 [WebDAV] contains
>    the line
>    <D:prop><R:DingALing/><R:Random/></D:prop>
>    As far as I understand, R as an undeclared namespace prefix,
>    as there is no declared R namespace in scope.  The line should
>    propably read as follows:
>    <D:prop xmlns:R="http://www.foo.bar/boxschema/">
>         <R:DingALing/><R:Random/>
>    </D:prop>
>

Good catch! This is definitely a bug in RFC 2518. I've added it to the
issues list.

> 5. Section 9.1 of [WebDAV] defines the DAV header as follows:
>    DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
>    I could not find any syntax rule for extend, neither in
>    [WebDAV], nor in [HTTP].  If extend may contain a ",", this
>    may lead to ambigous parsing; e.g. the string "DAV:1,2,3" could
>    be parsed with "2,3" representing the extend non-terminal.  Hence,
>    if extend has not been defined by now, it should at least be
>    further restricted, e.g. by requiring extend = token or
>    extend = quoted-string, with token and quoted-string being
>    defined in [HTTP].

Good catch!  We have, indeed, omitted a definition of the "extend"
production.  I have added this as well to the issues list.

Our intent was to have the production be:

extend = token       ; token is defined in [HTTP].


> 6. Is there a specific reason for WebDAV not making use of xml
>    element attributes?  I think, using attributes could both, speed
>    up parsing and simplify the grammar.
>    For example, elements exclusive and shared could be replaced by
>    a single enumerated attribute (see [XML] section 3.3.1, rule [57]
>    EnumeratedType) for element lockscope.

Yaron Goland is the main proponent of never using XML attributes, and his
rationale is presented here:
http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html

This is one of the "chapters" in the WebDAV Book of Why:
http://www.webdav.org/papers/#misc

- Jim

Received on Wednesday, 17 November 1999 21:02:31 UTC