RE: Comments on draft 04

You're appreciation is well, appreciated. =) I just spent the last two days
doing format changes to the spec. Such mind numbing work isn't much fun so
having someone occasional say "thanks" really makes a difference.

Schemas - The reason I am not a fan of the "supported schemas" property is
that I think we will run into problems because the property is likely to be
"live". So, speaking strictly from an implementation point of view, I
believe it will be extremely difficult to create a mechanism whereby
multiple independent extensions to a server will all be able to access and
set part of this property. I personally feel that a search based solution
works better. By defining a standard wrapper for schema information one can
then say to a resource "Return me all properties which contain this
wrapper." That way the resource will get back a complete list of all schemas
defined on the resource, without having to know their name, and without
forcing servers to define some mechanism to allow various extensions to
share the schema property.

>On the current proposal, schemas are treated as properties, but are unlike
>other properties in that there is no distinction between the schema
>definition and the schema value.  That is, the content of the schema's
>value is its definition.  This seems very unintuitive.

I would phrase it differently. The value of a particular property is the
definition of a particular schema. That seems very intuitive to me.

>The current proposal forces us to commit ourselves to a syntax for schema
>definition.

In what way? All it asks us to do is to wrap schemas in a known element so
they can be identified. Absolutely nothing is said about what is in that
element.

>A schema definition presumably won't tell you anything about which
>properties are treated as live by a given server, since the schema
>definition is independent of any particular server.  So if we want to be
>able to find out which properties are live for a given resource, let's put
>that information in the response to a PROPFIND/Propname request.

Actually, section 2.3.5 of the current spec defines how to list supported
properties. I also don't think the propname proposal is the best way to go
because it only states which of the current defined properties are live, not
which properties, if they were defined on the resource, would be live.

Re: Live properties

Our current definition of live only specifies that the value is enforced by
the resource, it says nothing about who actually sets the value. I think
this is the "read only" issue coming back to haunt us. I think that is
information that needs to be returned as part of the schema, which means we
leave it to the XML types to deal with. As for copying/moving, if the schema
says "only the resource may set this property's value" and the client
specifies that this property's schema must be enforced on the destination
then the destination better only allow the resource to set the property's
value. That doesn't mean, btw, that a value could not be suggested by the
client.

Referencing RDF - Is there a new requirement that all posts to the WebDAV
list must contain a request to referenced RDF? =) Yes, we will be adding a
reference to RDF.

2.5 Properties and URLs - By removing proploc we remove the mechanism which
allows properties to become resources, in this draft. However an extension
draft will be released in the future which specifies how to do proploc, how
to deal with properties that have URLs, and how to implement hierarchical
properties. The beauty is that you can do all of that by building on top of
DAV and without breaking ANY DAV compliant clients or servers. I just love
extensible protocols.

Iscollection - The current plan is to replace iscollection with a more
general element which identifies typing data.

>3.4.3 INDEX Request.  I like the new flexibility you have allowed in the
>INDEX response -- it MAY now include lists of members of child collections,
>and it MAY now include other properties in addition to the required core
>set.  But this is really only useful if the request can specify whether it
>wants to see recursive membership and which properties it wants to see in
>addition to the core set.  I think we should add these options to the
request.

Index is a precanned search. If you want to do general searches for
properties please use the search mechanism. A BOF for the DAV Search group
is supposed to be held at the December IETF. I really think we are making a
mistake by making INDEX any more complex than it currently is. The best
place, in my opinion, to put this complexity is in the SEARCH method.

>3.7.3 MOVE request.  Just for clarification, a request to MOVE a non-empty
>collection will fail.  Right?  Because a DELETE on a non-empty collection
>fails. 

Correct. I will add language to the spec to make this clearer.

>The proposal to remove PROPLOC from the specification bothers me partly
>because we are ending up with too many scattered specifications, and partly
>because I think there is too much optional stuff in WEBDAV.  The more we
>leave as optional, the less we have a standard.  I'm inclined to say,
>either leave it in and make it mandatory, or take it out altogether.

I agree so completely that I put out a call for exactly the same thing
several days ago. After discussing it with a number of people and seeing no
other responses on the group I have removed proploc from the DAV
specification. In general we are removing ALL optional features but locking.
In a specification this complex there are only two types of features,
mandatory and not implemented.

>3.2.3.2 MKCOL with Request Body.  I think we should define a standard
>request body that must be supported, or alternatively not support a request
>body for MKCOL at all.  Same rationale.

I do not think this group does the world any good by trying to pick the
"winning" format. There are many formats out there which can be potentially
used with MKCOL, almost all of them proprietary. By allowing MKCOL with a
request body we are simply providing a secure mechanism for submitting these
bodies that can be controlled through ACLs and such rather than forcing
implementers to create their own closed, non-interoperable, submission
mechanism.

>We have already defined three levels of compliance within the core
>specification.  It also is unclear to me what the status of the ancillary
>specifications (tree operations, versioning, ACL, PROPLOC, etc.) is
>supposed to be.  If all of these are optional features, that makes WEBDAV
>considerably less useful as a standard.

I appreciate your concern on this topic but without some specific proposal
to respond to, I'm not sure how to answer your concerns. I can say, however,
that the levels of compliance in the DAV spec are the result of common
sense. We can not require everyone to support versioning features. As
evidence by the fact that a tiny fraction of all servers support versioning,
this is a feature many people neither need nor want. So loosing a level of
DAV compliance by requiring, say, versioning support, does nothing but make
DAV irrelevant by foisting a feature many do not want upon them in the name
of "compliance." Locking is in a different position due to the compromises
we have had to make in the past. The locking issue has been discussed at
length on this list as well as at the various DAV meetings. The group has
repeatedly upheld the position that locking is optional, so I will not
revisit the issue here but encourage interested readers to review the
mailing list archives.

>(Even if these ancillary specs describe optional features, they should all
>be referenced from the base spec, so that people can find all the bits and
>pieces of WEBDAV.  If they do describe optional features, we need to state
>this explicitly, both in the base spec and in the ancillary specs.)

I would make a counter proposal. I believe that an informational RFC should
be created which explains all the DAV specs and how they relate to each
other. I would like to keep this information out of the DAV base spec
because I expect a fairly constant stream of extensions which would require
us to continually re-issue the spec with updates. An informational RFC, on
the other hand, can be updated without having to revisit the entire
protocol.

>That's it unless you want to hear about typos.

Actually, we do want to hear about typos. Typos have this nasty habit of
reducing clarity and thus leaving too much room for interpretation.

			Thanks again for your comments,
					Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Wednesday, October 22, 1997 10:57 AM
> To:	w3c-dist-auth@w3.org
> Subject:	Comments on draft 04
> 
> I just want to say that I hope the authors know how much we appreciate
> their work.  The spec looks better and better each time we see a new
> draft.
>  This is great!
> 
> Now, having said that . . . of course, I can't resist making some
> comments.
> 
> 2.3 Schemas
> 
> I would like to suggest a different way of handling schemas.  Let's have a
> DAV property called SupportedSchemas.  The value of this property is a
> list
> of schema names, where a schema name is a URI.
> 
> We don't define a PropSchema XML Element, but instead reference the RDF
> schema syntax (not yet defined).
> 
> This solves several problems with the current proposal:
> 
> 	On the current proposal, you can't ask "what schemas do you
> support?".
> You have to know a schema name, and ask whether that schema is supported.
> What's the test for schema identity?  Certainly not schema name, since the
> same schema may be defined at multiple URLs.  Syntactically identical
> schema definitions?  I think the right answer is semantically equivalent
> schema definitions.  So asking a resource whether it supports a given
> schema by asking about a particular schema name (URL) is not likely to be
> reliable anyhow.
> 
> 	On the current proposal, you can't tell whether any given property
> is a
> schema, except by retrieving the property value and examining it.
> 
> 	On the current proposal, schemas are treated as properties, but are
> unlike
> other properties in that there is no distinction between the schema
> definition and the schema value.  That is, the content of the schema's
> value is its definition.  This seems very unintuitive.
> 
> 	The current proposal forces us to commit ourselves to a syntax for
> schema
> definition.
> 
> A schema definition presumably won't tell you anything about which
> properties are treated as live by a given server, since the schema
> definition is independent of any particular server.  So if we want to be
> able to find out which properties are live for a given resource, let's put
> that information in the response to a PROPFIND/Propname request.
> 
> The definition of "live" is still unclear to me.  In 3.6.3.2, it is
> explained as "the server determines the syntax and semantics (hence value)
> of these properties."  But it does not follow from the fact that the
> server
> enforces syntax and semantics that it sets the value of a property.  If
> the
> valid values for a property are 0, 1, and 2, the server can enforce the
> syntax of that property by rejecting any other values, but still allow the
> client to set the property's value.  0 may mean that the server should
> never archive the resource, 1 may mean that the resource should be
> archived
> after 1 month of not being used, 2 may mean that the resource should be
> archived after 2 months of not being used.  The server may comply with
> this
> semantics.  So there are at least these two things you might be trying to
> get at with "live":
> 
> 	Server maintains the value itself -- client is not allowed to set
> the value
> 	Server makes sure that any value set complies with syntax and
> semantics
> defined for the property
> 
> We just need to figure out which of these we care about preserving when
> resources are copied / moved.
> 
> 2.4.3 Should we reference the RDF property syntax?
> 
> 2.5 Property Identifiers.  Properties are not resources unless they have
> URIs.  If PROPLOC gets removed from the spec, properties are never
> resources.
> 
> 3.3.1 IsCollection.  It might be useful to think about what other kinds of
> resources might usefully be tagged with their type. IsProperty (if
> properties can ever be resources) and IsSchema might also be useful.
> 
> 3.4.3 INDEX Request.  I like the new flexibility you have allowed in the
> INDEX response -- it MAY now include lists of members of child
> collections,
> and it MAY now include other properties in addition to the required core
> set.  But this is really only useful if the request can specify whether it
> wants to see recursive membership and which properties it wants to see in
> addition to the core set.  I think we should add these options to the
> request.
> 
> 3.7.3 MOVE request.  Just for clarification, a request to MOVE a non-empty
> collection will fail.  Right?  Because a DELETE on a non-empty collection
> fails. 
> 
> Optional Features
> 
> The proposal to remove PROPLOC from the specification bothers me partly
> because we are ending up with too many scattered specifications, and
> partly
> because I think there is too much optional stuff in WEBDAV.  The more we
> leave as optional, the less we have a standard.  I'm inclined to say,
> either leave it in and make it mandatory, or take it out altogether.
> 
> 3.2.3.2 MKCOL with Request Body.  I think we should define a standard
> request body that must be supported, or alternatively not support a
> request
> body for MKCOL at all.  Same rationale.
> 
> We have already defined three levels of compliance within the core
> specification.  It also is unclear to me what the status of the ancillary
> specifications (tree operations, versioning, ACL, PROPLOC, etc.) is
> supposed to be.  If all of these are optional features, that makes WEBDAV
> considerably less useful as a standard.
> 
> (Even if these ancillary specs describe optional features, they should all
> be referenced from the base spec, so that people can find all the bits and
> pieces of WEBDAV.  If they do describe optional features, we need to state
> this explicitly, both in the base spec and in the ancillary specs.)
> 
> That's it unless you want to hear about typos.
> 
> --Judy

Received on Wednesday, 22 October 1997 16:39:33 UTC