RE: Open Issues -- Attributes

Let us be clear on our terminology - There is no such thing as an
attribute in DAV. All that exists are links. The concept of attribute is
ill defined and DAV wisely avoids involving itself in that mire.

I will first address your points from the view of links.

1. It is impossible to require that the end of a link point back to its
source as this could require a server to server interaction and we do
not wish to involve ourselves in those issues. As has been previously
indicated, server to server issues are a quagmire and we don't want to
get stuck there. It is felt we can provide a useful specification w/out
having to deal w/server to server.

2. There have been a number of proposals for a mechanism to allow for
the bundling of multiple HTTP messages into a single message. For some
time the spec used to refer to a application/multipart that would allow
for the bundling of messages. This mechanism can be implemented
independently of DAV so I do not believe the DAV group should concern
itself w/it. However this mechanism will solve the problem of setting
multiple link values at once.

3. There is nothing in HTTP or DAV to prevent a server from acting as
you have indicated. The ability to discover this behavior is the basis
of the *HEAD commands. However it is becoming clear that there is not
sufficient interest to justify these commands.

4. It is up to the server to determine what links it will and will not
allow. Furthermore it is up to the server to create links whenever the
mood strikes.

The DAV spec does not prevent the server from creating, deleting, and
moving resources/links at any time it so desires. Rather, the DAV spec
describes how clients indicate what it is they wish to have done. The
results of every method, as they apply to links, are largely undefined.
This undefined behavior is required in order to allow servers to perform
as needed. However, we do provide a discovery mechanism, the link names.
Each link name is a token which should be registered and whose
definition will be generally available. This tells the client what to
expect from the server.

5. This information MAY be associated w/the definition of the link
token.

6. It has been assumed that the linkschema return format would indicate
if arbitrary link tokens are supported.

The above are the answers for the link issue. Attributes are more
complex. Links provide the infrastructure for attributes but do not
solve all attribute problems, like search. In the coming weeks I will be
posting a proposed standard for how to deal w/the attribute issues
detailed in your letter. I am currently working on that proposal.

		Yaron

> -----Original Message-----
> From:	Judith Slein [SMTP:slein@wrc.xerox.com]
> Sent:	Friday, February 07, 1997 9:07 AM
> To:	Jim Whitehead
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Open Issues -- Attributes
> 
> I have a number of concerns about how the spec treats attributes.
> Some are
> related to the very basic fact that we treat attributes as independent
> resources, linked to the resource they apply to.  Others are separate
> concerns:
> 
> Treating attributes as resources has some desirable consequences:
> 
> - Attributes are resources, and so can themselves have attributes.
> They can
> be versioned.  Content negotiation can be done for them.  Etc.
> 
> - An attribute can be shared by many resources.
> 
> - Attributes of a single resource can be distributed across multiple
> servers.
> 
> But treating attributes as resources also causes some serious
> problems:
> 
> 1. For many applications, the most important reason for having
> attributes is
> for searching.  It needs to be possible to search for a resource based
> upon
> the values of its attributes.  We may not want to specify anything
> about
> search syntax, but we do need to make sure that our attribute model
> can
> support reasonably efficient searches.  The very fact that our
> attributes
> are independent resources makes this difficult, and I don't see that
> we
> require attributes to point back to their resources, which would make
> it
> impossible.
> 
> 2. There is no way to set multiple attributes at a time. You would
> like to
> be able to set all attribute values for a document at the same time
> you put
> its content on the server, and change multiple attribute values in a
> single
> step at any time.
> 
> 3. This approach makes it extremely difficult to manage attributes. In
> the
> typical case, attributes should automatically get deleted when a
> document
> gets deleted - this won't happen. Neither will they get moved
> automatically
> with their document or copied automatically with their
> document. 
> 
> 4. Since attributes are resources, they can be linked to more than one
> resource.  So a link back to the parent is required in order to know
> whether
> an attribute can be deleted when one of its parents is deleted.
> 
> Other issues about attributes:
> 
> 5. How can you find out the constraints on values of attributes
> supported by
> a given server? Does this information come back when
> you ask for DAV.SupportedLinkTypes?  You need (arguably) to be able to
> find
> out the data type of an attribute, maximum length, valid values,
> whether its
> value can be a list, etc.
> 
> 6.  Is there a way to find out whether a server will let you assign
> attributes to a resource that do not belong to any well-known schema?
> 
> 
> A thought:
> 
> If links seem like the right implementation of attributes, we might
> want to
> have a separate section on links (which are really infrastructure on
> which
> attributes are based, and useful for many other things besides
> attributes)
> and a separate section on attributes.  I think this would make more
> certain
> that we address all issues related to attributes.
> 
> --Judy
> Name:			Judith A. Slein
> E-Mail:			slein@wrc.xerox.com
> Internal Phone:  	8*222-5169
> External Phone:		(716) 422-5169
> Fax:			(716) 265-7133
> MailStop:		128-29E
>

Received on Friday, 7 February 1997 23:44:13 UTC