RE: Comments on draft 04

The problem with properties and ACLs is the very reason why I am getting
rid of the ACL property and replacing it with the ACL method.

Also 2.3 is really more a suggestion then anything else. The main point
is to say "we need a standard wrapper", I did make some suggestions for
what should go in that wrapper and was viciously attacked in the
hallways of Microsoft by our local XML experts =). BTW I do not consider
the issue of schemas even close to closed and I do not consider my
current proposal as even being a terribly serious one. This is a
difficult issue, so difficult that in the next version of the draft it
is isolated in its own section. I think it is going to take us some more
time to really work this thing through.

The problem becomes a separation of parts. I personally envision a world
where a user can purchase their HTTP server with INDEX, COPY, etc.
support from one vendor and their property implementation from another.
Thus the first vendor can distinguish themselves by the quality of their
INDEX implementation and what properties they choose to make available
in it, this is a rich area for value adds. Especially since most of the
"properties" in INDEX are not properties at all but really values built
directly into the underlying implementation. By forcing INDEX to support
arbitrary property query we force the property implementer to implement
INDEX and thus remove the value add from the HTTP server vendor. We also
make the life of the property implementer more complex, forcing them to
implement a function which has more to do with the underlying server
vendor's implementation then with the issue of property support.

Additionally many systems will refuse to provide infinite INDEX support
because it is too expensive and too prone to unfairly reducing other
user's service. This was the crux of the whole tree vs flat method
debate. As such we can't require support of the "infinite" switch which
means the feature is optional which we both know means it effectively
might as well not exist in so far as a client can rely upon its
presence. Finally, we already provide a means to get the values of
properties on resources, it is called PROPFIND.

Finally, some systems will be unable to support either infinite INDEX or
queryable properties. The problem is virtual roots. Many servers are
actually several servers all living on the same machine, sharing the
same namespace. In many cases it is just impossible to do a fully
property query or an infinite INDEX as there is no way to propagate the
request for information to children who are virtual roots and then get
the results back and send them to the user. So by requiring the bundling
of this functionality you actually prevent flexible server
implementations. I would rather see a few more bits on the wire and a
little inconvenience to the client then hog tie server implementations.

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

What would it mean to "require" ACL support? If I don't want to
implement it then when you try the ACL method instead of getting a
truthful answer of "Method Not Supported", you will receive a nonsense
answer of "Access Denied."

Finally, I won't say I look forward to receiving the list of typos, but
I do promise I will fix them. =)

			Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, October 24, 1997 12:58 PM
> To:	Yaron Goland
> Cc:	'Judith Slein'; w3c-dist-auth@w3.org
> Subject:	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 16:38:42 UTC