Re: WebDAV spec should explicit say WebDAV XML is not valid

The spirit of DAV's use of XML is to allow the application to verify the
semantics of a well-formed XML request. That is the application verifies the
semantics of the DAV spec, but is free to interpret additional elements any way
it likes. Therefore the DAV DTD is not required or used, and the request entity
bodies do not need to be valid with respect to that DTD. However, the server is
responsible for interpreting the parsed contents in a manner compatible with
the DAV semantics.





w3c-dist-auth-request@w3.org on 07/23/98 09:58:54 PM
Please respond to w3c-dist-auth-request@w3.org
To: w3c-dist-auth@w3.org
cc:
Subject: WebDAV spec should explicit say WebDAV XML is not valid

As far as I can tell, the WebDAV spec never says explicitly that WebDAV XML
need not be valid.  It does say it must be well-formed (sections 3.4, 7),
and it does say that applications MUST ignore elements they do not
understand (sections 3.4, 13)  but it uses the magic word "valid".  Perhaps
it should say explicitly that it need not be valid, just to remove any doubt.

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.

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.

It would be a pity if applications tried to validate the XML and rejected
it.  We can forstall some confusion by stating plainly that the XML is not
expected to be valid.  Of course this also makes providing the XML DTD
somewhat pointless.

Received on Thursday, 23 July 1998 22:44:25 UTC