Some comments on -07 spec.

Jim Amsden privately sent me some comments on the -07 spec.  They're really 
good comments, so I have forwarded this thread along to the mailing list to 
they will be captured in the archives, and available for discussion. In the 
message below, the text after ">" belongs to Jim Amsden, the text after 
these comments belongs to me, and the text inside <jra>...</jra> blocks 
belongs to Jim Amsden again.

Of course, the only problem with this is that there are now too many Jim's! 
Between Jim Davis, Jim Cunningham, Jim Amsden, myself, and not to forget 
Jim Gettys working on HTTP/1.1, there's a significant Jim density!  Perhaps 
we should rename this to "Jim's Transfer Protocol (JTP)"... :-)

- Jim

-------------

Hi Jim,

Here are responses to your points.

On Wednesday, March 18, 1998 12:07 PM, Jim Amsden [SMTP:jamsden@us.ibm.com]
wrote:
> Some comments on version 07 of the WebDAV spec:
>
> 1. Section 7.10, LOCK does not explicitly state what is returned in the
> response entity. In example 7.10.8, a lockdiscovery prop is returned
while in
> 7.10.10, a multistatus is returned. It would seem that a multistatus
should be
> returned in all cases with a status for errors, and a propstat containing
a
> lockdiscovery prop for success.

In general, if the scope of a method is a whole resource and is applied to
just a single resource, then we default to use of HTTP/1.1 status
reporting.  It is only in cases where we're applying a method to
properties, or to multiple whole resources (or both) that we use the
multistatus response, since in these cases the standard HTTP 1.1 status
reporting is insufficient.

Since the introduction states that multistatus responses are for use for
methods which affect multiple resources, and since WebDAV is built on top
of HTTP/1.1 (and hence uses, by default, HTTP 1.1 status reporting), I'm
not sure what extra language needs to be added.

<jra>
But my question wasn't on single status respons vs. multi-status, it was on
<prop> vs. <multistatus> as the root document elements returned by LOCK.
Examples 7.10.8 and 7.10.9 return a <prop>. Example 7.10.10 returns a
<multistatus> containing a <response> that (could have) returned a <prop>
containing the <lockdiscovery>. It would simplify clients and servers if a
<multistatus> is returned in all cases so we don't have to figure out how 
to
parse the response body.

This is also a problem if you're trying to create a method that returns the
result of a LOCK as an object with accessors to obtain the information 
instead
of requiring clients to examine the DOM from the XML. The method would have 
to
return more than one type.
</jra>

> 2. Section 7.11, UNLOCK doesn't state what result is returned in the
response
> entity. Is it a multistatus containing the result of the UNLOCK, or the
> resources that prevented an UNLOCK from succeeding?

Since UNLOCK has all or nothing semantics, it is possible that UNLOCK can
simply return a single status code even when unlocking an entire collection
(i.e., 2xx means the UNLOCK worked, and 4xx means it didn't).  A smart
server could return a multistatus and a smart client could interpret this
to give a more intelligent error message.  At present, I'll admit that
unlock is underspecified in terms of what it should return in error cases
for unlocking a collection.

>
> 3. The DTD for WebDAV could be simplified by making use of element
attributes
> instead of contents in a number of cases. The DTD could be treated like a
data
> model with each element representing some object. The element contents
> represents a containment relationship to other elements while element
> attributes correspond to characteristics about the element. This also
allows
> the DTD to express more of the WebDAV semantics. For example:
>
>  <!DOCTYPE webdav-1.0 [
>
>    <!--============ XML Elements from Section 11 ==================-->
>
>    <!ELEMENT lockInfo (owner?) >
>    <!ATTLIST lockInfo
>         lockScope (exclusive | shared) "exclusive"
>         lockType (write) "write"
>         depth (this | members | children) "children"
>         timeout CDATA "infinite"
>         lockToken CDATA #IMPLIED
>    >
>
>    <!ELEMENT owner ANY >
>
>    <!ELEMENT href (#PCDATA) >
>
>    <!ELEMENT link EMPTY >
>    <!ATTLIST
>         source CDATA #REQUIRED
>         destination CDATA #REQUIRED
>    >
>
>    <!ELEMENT multiStatus (response+) >
>    <!ATTLIST multiStatus
>        description CDATA #IMPLIED
>    >
>
>    <!ELEMENT response (methodResponse | propeprtyResponse) >
>    <!ATTLIST response
>        resource CDATA #REQUIRED
>        description CDATA #IMPLIED
>    >
>
>    <!ELEMENT methodResponse (href*)>
>    <!ATTLIST methodResponse
>        status CDATA #REQUIRED
>    >
>
>    <!ELEMENT propertyResponse (property+)>
>    <!ATTLIST propertyResponse
>        status CDATA #REQUIRED
>    >
>
>    <!ELEMENT property ANY >
>
>    <!ELEMENT keepAlive (all | href* ) >
>    <!ELEMENT all EMPTY >
>
>    <!ELEMENT propertyUpdate (remove | set)+ >
>    <!ELEMENT remove (property) >
>    <!ELEMENT set (property) >
>
>    <!ELEMENT propfind (allprop | propname | prop) >
>    <!ELEMENT allprop EMPTY >
>    <!ELEMENT propname EMPTY >
>
>
>    <!--=========== Property Elements from Section 12 ===============-->
>
>    <!ELEMENT creationdate (#PCDATA) >
>    <!ELEMENT displayname (#PCDATA) >
>    <!ELEMENT getcontentlanguage (#PCDATA) >
>    <!ELEMENT getcontentlength (#PCDATA) >
>    <!ELEMENT getcontenttype (#PCDATA) >
>    <!ELEMENT getetag (#PCDATA) >
>    <!ELEMENT getlastmodified (#PCDATA) >
>    <!ELEMENT lockdiscovery (activelock)* >
>    <!ELEMENT resourcetype ANY >
>    <!ELEMENT source (link)* >
>    <!ELEMENT supportedlock (lockentry)* >
>
> ]>
>
> This isn't the complete DTD, and I haven't spent a lot of time thinking
about
> it, but it should give some ideas.

We gave this issue some thought during our design, and decided that it was
best to keep everything as elements.  In talking to XML and SGML folks, it
turns out that the choice of whether to keep something as an attribute or
an element is largely a matter of personal preference, since, as you point
out, they both have similar expressive power.  We also decided to stay with
elements only, since it simplifies things when dealing with namespaces, and
it means a WebDAV XML parser doesn't have to worry about parsing
attributes.

<jra>
The choice is somewhat a matter of personal preference, but not completely. 
If
you were developing an object (or entity relationship) model for the same
information, you probably wouldn't use an object for each primitive data 
type,
and use relationships to hook everyting together (unless of course you're 
using
Smalltalk!). There is a distinction between an attribute and a containment
relationship in object modeling - an object participating in a containment
relationship is existant dependent on its container, but may have a shorter
life-time of its own. It can also participate in relationships with other
objects (i.e., have direct collaborators). This is not true of attributes, 
so
they express a stronger constraint. There is an implication when you make 
some
thing an element that it might be contained in a number of other elements.
Making it an attribute is more specific about where the information might
appear, provides some minimal data typing, and supports specification of a
default value, all things that are not possible with elements. This is good
stuff to take advantage of where possible.

Attributes are scoped by the elements they're in, so there shouldn't be any
additional namespace issues.

All XML parsers must (and do) parse attributes. They are used extensively 
in
HTML already, and DOM supports them, even with JavaScript. This shouldn't 
be a
problem.

Having said all this, the current DTD is really fine. I just wanted to 
propose
some simplifications based on experiences with object and data modeling. I 
know
it's late to introduce changes of this magnitude.
</jra>

> 4. Elements lockinfo and collection don't appear to be used. I changed
> activelock to lockInfo in the example above. Its more descriptive of what
the
> element is about, and groups together all the information a client needs
to
> send in the request in one place instead of putting some of it in the
headers
> and some in the request entity. I agree with the logic for when to put

> information in headers and when to put it in an entity request body
except that
> once you have decided to use an entity request body, all parameters
should be
> placed in the body, not some in headers. This simplifies the programming
and
> makes the request more cohesive.

The lockinfo element is only used in the request body of a LOCK request,
and it specifies the characteristics of the desired lock.  The activelock
element is used within the lockdiscovery property, which is the mechanism
by which the client can request a listing of all the active locks on a
particular resource (hence "activelock").

We've gone back and forth on whether to put parameters in headers or in the
body.  In the case of LOCK, having the timeout information in the header
makes it possible to submit a request to refresh a lock (see 7.10.9)
without having to submit a request body.

> 5. omit is the same thing as an empty keepalive. Using an all element
avoids
> mixed content in propertyupdate. something that is usually a good idea in
XML.
> Then propertybehavior can reduce to just keepalive. This is simpler, and
> reflects the semantics a little clearer.

There's a slight difference between a blank keepalive and omit, since the
semantics of keepalive are specific to live properties, while omit applies
to both live and non-live properties.  So, a blank keepalive (an error,
really) means to keep live no live properties, and hence use the default
copy/move semantics of failure if a property cannot be copied, and omit
changes the semantics of copy/move so not being able to copy/move a
property isn't an error.

> 6. What does it mean for a locktoken to have more than one href? No href?
How
> can an activelock not have a locktoken? Note that in the example DTD
above,
> lockToken is #IMPLIED because lockInfo is used both on the request and
the
> response.

If there are multiple hrefs, it means there is more than one URI which
identifies the given lock.  We felt this might become important in the
future (perhaps with a DAV server managing a lock which actually spans
multiple repositories).  As for an empty locktoken, that is certainly
semantically incorrect, and it seems to me we can change the production
from (href*) to (href+).

> 7. It might be a good idea to avoid abreviations and to use the naming
> convention that new words in an identifier start with a capital letter in
order
> to make the XML more readable.

At this point, since there are several prototype implementations of WebDAV,
and since this is a relatively minor point, my inclination is to leave them
as-is.  It sounds like a lot of work for minor benefit.

<jra>
agreed.
</jra>

Received on Friday, 20 March 1998 17:51:03 UTC