Subject: Syntax Issues

From: Juergen Reuter <[email-masked]>
Date: Wed, 17 Nov 1999 18:56:29 +0100

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

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?

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.

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>

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

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 17 Nov 1999 18:01:00 -0800

>    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!

>    propertyupdate | propertybehaviour | lockinfo | prop) >

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.

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

>         <R:DingALing/><R:Random/>

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

>    extend = quoted-string, with token and quoted-string being

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

>    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

---

From: Greg Stein <[email-masked]>
Date: Thu, 18 Nov 1999 00:06:19 -0800 (PST)

On Wed, 17 Nov 1999, Juergen Reuter wrote:
>...

Wow. I didn't realize that IE5 and Office 2000 were not "real-life
applications." After all, they don't check against a DTD.

<SarcasmOff/>

I've been able to implement a DAV server without the "benefit" of a DTD.
Works great. Many other people have done servers, too. There aren't so
many clients, but they all work very well. All without the benefit of a
DTD.

The rest of your email was great.... But I had to say something about your
supposition. It just isn't true that a DTD is required or even needed.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: Juergen Reuter <[email-masked]>
Date: Wed, 24 Nov 1999 16:28:51 +0100

Many thanks for your detailed and constructive answer!  Still some
issues are left...

> isn't a problem because we don't require validity.

Ok, on the [WebDAV] issues list, I found the XML_NOT_VALID issue
stating that the specification should explicitly note that the XML is
not valid (although, I finally found that, in fact, [WebDAV] already
explicitly notes this in section 17.7; but it should also be noted in
the introduction).

> interoperation.
> Since there is a finite set of XML elements used within
> combining them, doing strict XML validity checking doesn't add much.

As far as I understand, WebDAV's DTD itself is fixed; but the examples
in chapter 8 use a namespace identified by the external entity
reference URI "http://www.foo.bar/boxschema", which, effectively,
extends the syntax.

> On the
> prescriptively in the XML DTD language.

Then it should not be too difficult to apply those small changes that
should make WebDAV validatable?

> So, while DAV doesn't require XML

Ok, I understand that there might be reasons for some implementors not
to use validation.  On the other hand, I think validating xml could be
implicitly introduced into [WebDAV], thereby allowing each implementor
to decide on his own whether to use validation or not.  The current
syntax, however, makes it impossible to use validation, unless an
additional input filter is supplied that patches the input data, or a
validating parser is patched to accept even [WebDAV]'s syntax.

On Thu, 23 Jul 1998 19:04:28 PDT, Jim Davis ([email-masked]) wrote:
> And lest you have any doubt, the spec contains examples of invalid
> (although well-formed) XML.  For example the prop XML element is defined as
> ANY, and the  XML spec (section 3.2) says that ANY means "any declared
> element type", but in general, client properties will not have been
> declared in the DTD, hence this XML will be well formed but not valid.

However, this is not a problem, because in section 2.8 [XML] says:
"The document type declaration can point to an external subset ..., or
contain the markup declarations directly ..., or can do both."  This
means client properties do not need to be declared in the DTD, but can
also be declared directly as markup declarations in the submitted
document.

> It's also a pity that there's no way in XML (that I see) to declare an
> element's contents to truly be "any".  This would allow you to validate
> WebDAV XML in those places that mattered (e.g. propertybehavior) and not in
> those places that are open ended (resourcetype).  But this can't be helped.

With the above said, there is no reason to declare an element's
contents to truly be "any".

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

Ok.  Probably extend should be further restricted to be any other
token than the string "2".

> http://lists.w3.org/Archives/Public/w3c-dist-auth/1998JulSep/0084.html

Ok.  When regarding extensibility of the specification, not using
element attributes might be the better choice, even if parsing might
become slower and more memory exhausting (at least for my
current implementation).

Bye,
     Juergen

---

From: Juergen Reuter <[email-masked]>
Date: Wed, 24 Nov 1999 16:32:38 +0100

> applications." After all, they don't check against a DTD.

I am rather using Netscape for surfing and emacs/LaTeX for word
processing; hence I do not know much about the products that you
mentioned, and therefore I do not feel authorized to classify
them as being anything. ;-)

> many clients, but they all work very well. All without the benefit of a

How do you know?  I suppose, you did not proof their correctness...
Actually, I found the invalid xml element declaration, which I
reported in my preceding mail, by using a validating parser to parse
WebDAV's DTD.  Though I notice, that validation can not guarantee
correctness, I think that a validiating parser, if sensibly applied,
can reduce the risk of introducing implementation (and possibly
specification) bugs.

Bye,
     Juergen