Re: DTD Confusion

   There seem to be some confusion as to how DTD work.

I don't think there is any confusion about how DTD's work,
but rather a disagreement about the value provided by a DTD.

   The tendency of the
   authors of the DeltaV document to write ANY in every place that one
   would like to be able to the protocol is both unnecessary and unhelpful.

The purpose of ANY in the protocol usually indicates that there is
no DTD construct that usefully describes the syntactic constraints
on what elements can appear, and therefore those constraints are
described in English text.

   In particular, a DTD is similar to a BNF for a language: a parser need
   not use the BNF directly to parse the language, but It still gives
   implementers a way of precisely describing the language.

DTD's provide a very limited vocabulary for describing the syntax.
In the case of the versioning protocol, we mostly need the ability
to say "at most one of each of the following element types can
appear, in any order".  Unfortunately, there is no DTD construct
to express this, so we use (very) simple English text to describe
this constraint.

   This conception seems to be in the manner that validation is
   interpreted. There seems to be the view that if a server validates its
   input and a client makes a request with an extended DTD,the server will
   not recognize some new tag and thus reject the request.

If someone thought that, I agree they would be confused.

   Of course, this
   would be contrary to the spirit of this protocol.  However, validation
   does not work this way.  If a client sends a message based on a new DTD,
   it causes no problem.  The client must send a copy or a reference of the
   new DTD with its message.  The server has two choices: it may fetch the
   new DTD and validate against that DTD, or the server may simply check
   for well-formedness. In both cases, the server need not and should not
   reject the request, so long as the request matches the given DTD.  If it
   does not match, however, something is in fact wrong with the request.=20
   Even in this case, the server is still permitted to recover from the
   error.  The same applies in reverse for responses from the client.

Yes, and this illustrates the very limited value of including a DTD
(or a reference to a DTD) in a message.  If the message is valid (wrt
the DTD), the DTD has no effect on how the message is processed.  If
the message isn't something the receiver can process, it will be
rejected whether it is valid or not.  So the only case where a DTD
matters is where the client can process the message, but it doesn't
match the DTD that was sent.  As you state above, the recipient may
well want to process the message anyway in this case, and ignore the
fact that the message didn't match the DTD that it came with.

Because of this, our implementations will not send DTD's (or references
to DTD's) with our messages, nor will we process any DTD's (or references
to DTD's) that are included.  What matters to us is whether we can
process the message, not whether it matches some DTD.

   We opine that a client or a server should be able to send messages that
   conform to the DTD that it uses.   This does not inhibit communication
   with peers that use another version of the protocol.

I agree, as long as we do not require that a DTD (or a reference to a DTD)
be sent, and we do not require that a DTD (or a reference to a DTD) be
processed by the receiver of the message.

   Each new version
   must have its own DTD, but this should be a good basis for understanding
   what the protocol actually is in any given version and how it changes
   from one version to the next.  A well designed DTD should also help
   insure that new version are, in fact, upwardly compatible.

The fact that new variants are syntactically compatible with old
variants is rather trivial to verify, with or without the use of
DTD's.  The hard part is making sure that the semantics is upwardly
compatible.  But in any case, DTD's do not help when they do not have
the capability of describing the syntactic constraints of a particular
type of message (as is the case for the versioning messages).

Cheers,
Geoff

Received on Sunday, 4 February 2001 14:18:36 UTC