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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dennis E. Hamilton
> Sent: Saturday, October 18, 2003 1:33 AM
> To: Julian Reschke; w3c-dist-auth@w3.org
> Subject: 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]

Yes, I agree that if we don't mean "ANY", we shouldn't say so. Or if we
continue to say so, that ANY comes with a comment line saying what it means.
See, for instance:

<http://greenbytes.de/tech/webdav/rfc3253.html#PROPERTY_supported-live-prope
rty-set>

(side note: the HTML versions of the RFCs on our web page contain DCMI
metadata encoded in the format specified in RFC2774)

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

Correct.

> 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

Actually, multiple instances of ordering-type are illegal. That's why the
DTD says "?".

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

Right.

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

in Relax NG Compact Syntax, this would be:

	namespace dav = "DAV:"
	orderpatch = element dav:oderpatch (ordering-type? & order-member* & EXT*)

	ordering-type = element dav:ordering-type ...
	(and so on...)

So in theory we could just borrow the "&" notation (which is the same as ","
except that ordering isn't significant), and use EXT (or any other
identifier) to denote elemements not defined by the spec (and other base
specs). So I'd prefer:

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

(of course this is also a demonstration about why the RelaxNG Compact
Notation is very popular around former DTD users).

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

Actually, RFC2518 is vague about how mixed content and extensibility work
together. Technically it says that anything can be extended, however I
assume that almost all implementations get very confused when I start
extending elements with text content, such as

	<d:getcontentlenght>123<bytes/></d:getcontentlength>

although I think this conforms to the spec. So a conservative approach would
be to limit extensibility to elements that do not have text content, and not
to allow text content as extension.

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

%orderpatch would need to represent all elements not defined in the relevant
specs, in RNC:

	EXT = * - (dav:allprop | dav:href | dav:multistatus | dav:prop |
dav:propfind | dav:propname )
		{ any }

(of course the list is incomplete...).

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

No.

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

We discussed this just a few days ago. I wouldn't call the content model of
<prop> "extensible". Whatever you put there is defined by the spec (as
identifier of a property). I'd like to use the term "extensibility" when we
speak about things *not* defined by the spec (such as adding new child
elements to DAV:response).

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

I didn't get that. Could you please explain?

> It's a mystery.

I don't think it's that bad. Except for one particular client, it doesn't
seem to have caused actual interoperability problems so far.

Julian

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

Received on Friday, 17 October 2003 20:17:44 UTC