RE: Comments on draft 04

At 01:38 PM 10/22/97 PDT, Yaron Goland wrote:
>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.

Well, maybe.  Won't the server have to solve this problem for other live
properties (like access control) anyhow?  A Documentum gateway, for
example, would have a whole different set of access types than the standard
WebDAV set.  (View attributes, view content, annotate, create version,
modify content, delete)

>
>>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.

I guess what seems weird is that the definition and the value are the same
(or close).  See next comment.

>
>>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.

We do define schema in 2.3.1, and it's likely that this definition of
schema will not be the same as RDF's definition.  This is one thing that's
confusing, I guess.  Maybe I don't understand what you were saying in 2.3.
Here's what I thought was happening:  The property name should be something
like http://www.oclc.org/DublinCore, which points to the RDF schema
definition on the oclc server.  Then the value of the property on the
particular resource replicates the schema definition and provides one piece
of additional information (for each property in the schema, whether it is
treated as live for this resource).  (Each property DTD in the schema value
also replicates the information contained in the property definition
pointed to by the property name on the resource.)

Another question I had is whether a resource can have a property that is
not defined as part of any schema.

>
>>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.

True

>
>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.

So you should take out the parenthetical "(hence value)" from 3.6.3.2.

>
>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.
>

I've suspected for a long time that we have very different notions of what
"search" means.  I think of there being three distinct approaches to
finding objects in a domain:  (1) by reference, (2) by navigation /
browsing / following links, (3) by query.  INDEX falls into category (2),
and search falls into category (3). INDEX is Windows File Manager, and just
as in Windows File Manager, I can specify which properties of the files in
a directory I want to see, so in INDEX I should be able to specify which
properties of the resources I want to see.  (OK, so this capability
disappeared from Windows Explorer, a mistake if you ask me!)  SEARCH is the
Find tool.  A search would be a method for filtering out resources from the
domain.

I would rather see the SEARCH activity focused on a query mechanism, and
not meddling with methods defined in the core of WebDAV.  I think it would
be better to make INDEX as sophisticated as we want it now, and keep the
search activity working on a QUERY method.

All we would need to add to the INDEX request is a switch for saying one
level / all levels, and a property list.  This looks pretty simple.

>>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.

The levels of compliance are probably unavoidable.  What would you say if I
proposed that ACL support is required? That support for TREE methods is
required?

>
>>(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.

This sounds good to me.

>
>>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.

I'll send you a list over the weekend.

--Judy

Received on Friday, 24 October 1997 15:55:10 UTC