Re: DTD Confusion

Dear Geoff,

      From: "James J. Hunt" <jjh@ira.uka.de>

      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.

   OK, sounds like we're all set there then.

      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.

   That's OK with me.  For everyone who hasn't read James' DTD, this just
   says that you get back:
    <DAV:error> <DAV:some-error-element/> </DAV:error>
   I assume this is to allow you to return multiple error elements?

That and I can use the same construct in propstat in the place of or
parallel to responsedescription.

   Any objections?

      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.

   I think I'll need more than "not very clean".  The mechanism in the
   current protocol is not order sensitive (i.e. does not require that a
   particular element type be "first"), which is better for
   extensibility.

A better explanation is perhaps in order, but I do not see your object
in regards to order sensitivity.  Your example has an order that is
implicit.  There must be an associatition between the variable value or
request at one level and the next set of variable values or requests at
the next deeper level.  I would like to make this relationship explicit
with multiprop and prop-apply respectively.  No additional order
constraints are made.

Sincerely,
James J. Hunt

Received on Tuesday, 13 February 2001 11:59:15 UTC