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 14:20:17 UTC