Syntax Issues from Juergen Reuter on 1999-11-17 (w3c-dist-auth@w3.org from October to December 1999) (original) (raw)

Hi all!

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

    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

    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

    where element all would effectively replace the '"*"' PCDATA of the keepalive 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 . 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

    solve this problem?

  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:

    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.

  4. The response in the example in section 8.1.1 [WebDAV] contains the line <D:prop><R:DingALing/><R:Random/> 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/>

  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].

  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.

I hope I could present my issues clearly enough. Many thanks in advance!

Bye, Juergen

Received on Wednesday, 17 November 1999 13:00:17 UTC