Re: DTD Confusion

Dear Geoff and Jim,

The last DTD that I posted is in fact one DTD for each message packed
together in one file.  There is a lot of common code in it.  I could
modify it to have one common section that is included by a short message
based DTD header for each message where it is necessary.  The only place
where that is actually needed is if one would like to reuse set and
friends in LABEL.  I could live with that.

There are two places in the protocol where I would like to clean up a
bit and it is not just a DTD issue.  One is that handling of error
return information.  I would like a top level error element as given at
the end of my DTD proposal.  The second is the way the expand-property
report sends information.  I do not want to nest prop elements in prop
elements.  I is just not very clean.  I made a suggestion to this effect,
but there was almost not comment on it.

The DTD information given in the WebDAV spec is much better than what is
given in the DeltaV spec.  There are some problems with the way it is
written, but nothing that prevented me from using it as a basis for a
fully compatible DeltaV spec.

Jim. You have stated before that a complete object model is more
important.  A DTD describes what can be sent.  It is true that it is not
sufficient, but it certainly does not hurt.  I can only say, I have
provided a possible DTD and am willing to finish the job to answer all
concerns.  I would be a tremendous contribution if you would provide the
semantic model to complement it.

Sincerely,
James

   I agree with all of Jim's points below.

   My only thought was that if the DTD advocates were comfortable with
   this statement, that I could add a statement in the notation
   convention section that the document specifies the DTD for each type of
   message, and that the definition of an element in the DTD of one
   type of message can in general differ from the DTD for that element in
   another
   type of message.  For example, the DAV:set element in PROPFIND and the
   LABEL method.

   Cheers,
   Geoff 

   -----Original Message-----
   From: Jim Amsden [mailto:jamsden@us.ibm.com]

   ... this is really a WebDAV issue too, so the WebDAV working group should
   get involved. If they aren't interested in providing DTDs, then there
   probably isn't much point in Delta-V doing providing a partial set. Also
   note that having the DTDs should never require clients or servers to use
   them. They won't help formalize the extensions either. Personally I'm more
   interested in getting the semantics understood and formalized. DTDs can't do
   this, they only do structure. A good, complete object model, including
   behavior, state models, and/or interaction diatrams (or collaboration graphs
   depending on your preference) would be much more useful. 




   "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> 

   A compromise suggestion for those interested in DTD's:

   Each of the WebDAV messages are a separate XML document.
   If you design a separate DTD for each WebDAV message type
   (i.e. one for a PROPFIND request, one for a PROPFIND response,
   one for a CHECKIN request, etc.), I believe you will find
   that all the anomalies disappear.  In addition,
   I believe this will produce a set of much more manageable,
   extensible DTD's than would be provided by trying to
   amass all WebDAV DTD information into one massive DTD.

   Cheers,
   Geoff

Received on Friday, 9 February 2001 09:39:07 UTC