W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

RE: must property names be empty and attributeless?

From: John Tigue <jtigue@DataChannel.com>
Date: Wed, 15 Jul 1998 15:21:52 -0700
Message-ID: <4435AEE04AAED111A41F00A0C99B60230FD1E0@ZEUS>
To: Jim Davis <jdavis@parc.xerox.com>, John Tigue <jtigue@DataChannel.com>, w3c-dist-auth@w3.org
<snip />
> At 11:15 AM 7/15/98 PDT, John Tigue wrote:
> >...the DTD could be modified to make it impossible to
> >have attributes associated with the properties being requested 
> I take it that you think the answer then is "yes", that this 
> restriction is
> intended but was just never stated?

I do believe it was intended but that's for others to say.

> If so, your proposed solution is overkill.  If you want to restrict
> property elements to being both empty and attribute-less, 
> it's fine to just
> say so in natural language in the spec.  I think it's fine if the DTD
> overgenerates (to use a technical term).  You can add additional
> restructions in english or in EBNF if you really want precision.  The
> expressive power of the DTD language is too low, and if we 
> tried to define
> the syntax so that we could ensure that every document that was valid
> according to the DTD was also legal WebDAV, we'd have to 
> tweak the spec
> considerably.

As I said earlier in the thread:
> (Perhaps this document is simply for use in any future WebDAV work)

I am not suggesting that we go back and modfify what is already done. I
am simply trying to point out that if this sort of issue comes up again
in future WebDAV work then there is a solution. 

In this thread, we are talking about XML so I would use the (admittedly
weak) existing power of DTDs to constrain the syntax just as I would use
EBNF where appropiate. We already have XML 1.0 and parsers. By using
what DTD syntax constraints we currently have, a parser can be used
during developement as a debug tool in order to maximize
interoperability. During developement, use a validating XML processor
for spec checking and during deployment use simply a well-formedness
processor for performance. 

By leveraging the "power" of DTDs we can increase interoperability. If a
desired feature can be expressed equally well in prose and in DTD syntax
then I would go for DTD; a DTD into a parser is more precise than spec
prose into a human. The overgenerating feature (attributes) is one of
the nice things about XML but, from Yaron's comments, I do not think
that feature is desirable for PROPFIND. 

Too late for PROPFIND but NMTOKEN attributes are useful and would have
been appropriate for PROPFIND, I believe. If this type of design choice
faces us again, I would use NMTOKENs in attributes.
Received on Wednesday, 15 July 1998 18:25:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC