Re: Syntax Issues

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

On Wed, 17 Nov 1999 18:01:00 -0800, Jim Whitehead <ejw@ics.uci.edu> wrote:
> 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.

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

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

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

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

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

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 (jdavis@parc.xerox.com) 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".

On Wed, 17 Nov 1999 18:01:00 -0800, Jim Whitehead <ejw@ics.uci.edu> wrote:
> extend = token       ; token is defined in [HTTP].

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

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

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

Received on Wednesday, 24 November 1999 10:29:14 UTC