RE: DTD-Fragment Approach (was Re: How to use DTDs, or not to ...)

Good summary.

I looked at the ordering specification.  

1.	I would suggest that some other form than ANY be used to mean that there is an open content model with nothing said about it.  Maybe an invented form like "(...)"   [or even %:... oddly enough]

2.	With regard to the statement about ordering, it may be necessary to say more.  For example, in

	<!ELEMENT orderpatch (ordering-type?, order-member*) >

I would read this, in terms of order being unimportant, as providing for at most one <ordering-type> element, none or more <order-member> and extension elements, all in any order.

I assume that if there are multiple <ordering-type> elements, it is the ones after the first that must be ignored if that usage is not understood.  On the other hand, an example in rfc2518 section 23 (and bis-04 section 24) would indicate that a second occurrence of <ordering-type> is illegal and must be rejected with a 400 response.  (See (4) below).

3.	A lax DTD fragment for all of that is something like

	<!ELEMENT orderpatch (ordering-type | order-member %:...)*>

where other conditions on multiplicity are stated in the text [and, in this example, %:... can be defaulted to the empty string or some hypothetical sequence beginning with "| ".  

3.1	Does appearance of mixed content qualify as an extended use?  Then it would be

	<!ELEMENT orderpatch (#PCDATA | ordering-type | order-member %:... )* >

If you really mean that ANY DAV-defined element can potentially be here as well as any other (i.e., <error>, <make-collection>, and so on), that is the best that can be done in a DTD that does not exclude any possibly-valid element, leaving the rest up to the DAV processor.

3.2	In a narrower notion of what an admissible extension could be, it might be more useful to consider

	<!ELEMENT orderpatch (ordering-type | order-member %orderpatch:... )* >

with the side stipulation that there be at most one <ordering-type> element.  I would give this the reading that there may be any number of potentially-acceptable <orderpatch>-extension content elements other than those explicitly identified.  That is, the conditions on admissible ordering-type and order-member occurrences are not modifiable by extension to the <orderpatch> element.

4.	Is there any more-precise definition of extension than the one in this part of the ordered-collection specification and in rfc2518 section 23?  (rfc2518bis-04 section 24?)  

4.1	I am thinking there is a difference between an extension and an application involving ad hoc additions, as in the content of a <proc> element, but perhaps it is all regarded as extension.  

4.2	It also would seem, based on the example of a mandatory 400 response, that extensions cannot contradict the multiplicity given in 2518 or any extension specification (as honored in 3.2).  

It's a mystery.

-- Dennis

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke
Sent: Friday, October 17, 2003 13:45
To: w3c-dist-auth@w3.org
Subject: RE: How to use DTDs, or not to (was: RE: ACL and lockdiscovery)

[ ... ]

So it seems there's no support at all for a major change. Let's fix just the
issues that we have with the DTD fragments. I'd suggest to re-read what the
ordering spec currently says and, if necessary, to clarify it. Then we can
use that in all other specs.


Julian


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 17 October 2003 19:33:03 UTC