RE: Open Issues -- Attributes

At 08:43 PM 2/7/97 PST, Yaron Goland wrote:

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

Speaking for the document management camp, attributes are centrally
important to the services we provide.  And probably the most important use
of attributes for us is as a way to search for documents.  That means that
we have to be able to figure out what document a given attributes belongs
to.  Will Microsoft have an interest in this, too?  You can already assign
attributes, including custom attributes, to documents created by MS tools.
Surely the day is coming when it will be possible to search based on the
values of those attributes.  Will the Web be part of this picture?

This could push us in one of two directions:  Either we could bite the
bullet and think about server to server interaction, or we could give up the
strategy of treating attributes as resources connected to documents by links.

(Of course, there are many applications around attributes that do not
involve search, like resource ratings.  And we could elect to support only
these, but I don't like the idea of defining an attribute mechanism that
cannot support search -- then somebody else will just have to develop a
competing mechanism that can.)

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

I agree that somehow using MIME multipart content could solve this problem,
but I'm not sure it can be done without making some change someplace in DAV
to accommodate it.  Did you have in mind that each body part of the
multipart message would itself be a SETLINKVAL request?  Then what kind of
request is the top level message that has the multipart/mixed as its body?

I'll send separate mail on the Warwick Framework which tries to do some
bundling of attributes, potentially using MIME multipart content to do the
bundling.
>
>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.

3/4 are related to the controversy we had at Irvine about how much
flexibility we should allow servers, how much discovery responsibility we
want to put on clients, etc.  The group needs to come to some agreement on
these questions before the next rev of the spec.

My own inclination is to keep it simple.  But by hiding the complexity of
the situation from the client rather than by constraining the server.  We
might provide a flag on the MOVE, COPY, and DELETE requests so that the
client can request that user attributes be / not be moved, copied, or
deleted with the resource.  If the server cannot comply or has a policy
against it, the request fails.  If the client doesn't use the flag, the
server does whatever it likes.  Again I want to point out that without back
links from an attribute to its resources, the server cannot implement an
intelligent policy.

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

OK. Syntax needs to be defined.
>
>6. It has been assumed that the linkschema return format would indicate
>if arbitrary link tokens are supported.

OK. Syntax needs to be defined.
>
>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.

Looking forward to seeing it.  Thanks for your thoughts on links in the
meantime.

--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 Tuesday, 11 February 1997 10:27:00 UTC