Design Team Notes: Links/Attributes/Metadata

DESIGN TEAM NOTES

First WEBDAV Design Team Meeting

December 18-20, 1996

Novell, Orem, Utah

In attendance:
  Stephen Carter, Novell
  Asad Faizi, Netscape
  Yaron Goland, Microsoft
  Del Jensen, Novell
  Jim Whitehead, U.C. Irvine


The first WEBDAV Design Team meeting was held from December 18-20,
1996, at the Orem, Utah campus of Novell.  Many thanks to Stephen
Carter and Novell for hosting this meeting.  Thanks also to Del
Jensen, who took meeting notes which were used in the creation of this
message. The purpose of the Design Team meeting was to gather a small
group who would work intensely for several days to develop and refine
the WEBDAV protocol specification.  Since this was a closed meeting,
the draft protocol specification reflects only the opinions of the
participants of the Design Team meeting, who have tried to represent
the working group as a whole.  However, the decisions made at the
Design Team meeting are subject review and acceptance by the WEBDAV
working group as a whole, which is the only proper polling point for
determining consensus.

There were four main topics of discussion during the Design Team
meeting: Links/Attributes/Metadata, Locking, Collections, Namespace
manipulation.  This message describes the results of our discussion
on links, attributes, and metadata.

LINKS, ATTRIBUTES, METADATA

The team began its discussions by reviewing the "light link" proposal.
A light link contains only a source URI, a destination URI, and a type
token. The source URI is the beginning of the link, the destination
URI is the endpoint of the link, and the type describes the
relationship between the source and destination resources.  A link may
be interpreted as a binary relationship between the source and
destination resources, which has the meaning, "the destination
resource contains information of relation <type> to the source
resource."  A link may also be interpreted as an attribute-value pair,
where the attribute name is the link type, and the value is pointed to
by the destination of the link.

This proposal was criticized for two reasons.  First, when using a
link as an attribute-value pair, it requires two HTTP requests to
retrieve the value information.  This overhead was perceived to be
high, especially for small information values, such as a date field.
Second, the light link proposal seemed to arbitrarily reject the link
method and header described in Section 19.6 of the HTTP/1.1
specification.  Surely the HTTP community would object to an arbitrary
rejection of an existing proposal for the same functionality.

The Design Team then began a detailed consideration of HTTP/1.1 style
links, eventually ending up with a link which contained the following
fields:

  Source     : URI          ; the beginning of the link
  Destination: URI          ; the endpoint of the link
  type       : token        ; the type of the link
  anchor     : 1*("(" media-type "," token ")")  ; information about where
                                                   the link ends in the
                                                   destination resource,
                                                   by media-type (in case
                                                   of content negotiation).
  value      : UTF-8        ; the value of an attribute-value pair
  title      : UTF-8        ; the title of the link

While initially seeming like a good idea, several questions arose with
this formulation of links.  What is the difference between a link and
a resource when a link contains a title and a value field which may
contain arbitrary content?  Since value and title may be in any language,
how is content negotiation performed on these fields?  How should two
links be considered identical?  How should a link be identified for
link removal operations?

We struggled to save the HTTP/1.1 style link approach.  A user-agent
could use content negotiation when requesting the contents of a link
to retrieve value and title fields in the desired language.  However,
this requires adding a language tag to each value field, and
specifying the language when setting the value.  It also raises the
need for a link modification method, so that the value and title can
be changed without modifying the rest of the link contents.  Adding
anchor, value, and title fields, and language tags to value and title
fields would also increase the complexity of link searches.

Identifying a link for removal or modification was discussed, with two
options being fielded.  The first was to exactly specify the value of
every field, and demand exact matches on every field.  However, this
is a potentially high-bandwidth solution due to the potential for
value and title fields to have entries in multiple languages, and all
would need to be exactly specified.  The second alternativewas to have
a link identifier tag for each link which is assigned upon creation.
This approach has the drawback that it is difficult for the server to
assign unique link ids, and there was some debate over whether the
link ids would need to be globally unique, or could be unique to each
resource.  We also discussed the possibility that a hash could be used
to develop the link identifier, but this was considered undesirable
due to the processing required by the server to compute the hash.

After considering the HTTP/1.1 style link approach for close to a day,
we came to the conclusion that it definitely increased the complexity
of our solution.  What did we gain from this extra complexity?  The
anchor, value, and title fields.  We pondered whether the tradeoff
of extra complexity versus one round trip access of value information
was worth making.  We considered five alternative link formulations:

1. Src, Dest, Type (original light link proposal)
2. Src, Dest, Type, Anchor  (remove all negotiable content)
3. Src, Dest, Type, Value   (reduce the amount of negotiable content)
4. Src, Dest, Type, Anchor, Value
5. Full first-class links (which were vaguely defined)

We decided to adopt alternative 1, the original light link proposal,
due to its simplicity, and the reduction in complexity in link manipulating
methods.  This type of link is specified as:

Source: URI
Destination: URI
Type: token

However, we still wanted to be able to retrieve the contents of the
destination resource of a link with a single round trip (one method
invocation).  This was accomplished be defining a method called
GetLinkVal.  GetLinkVal is passed a link type and a Request-URI, and it
searches the Request-URI for links with matching types.  If the source
URI of the link matches the Request-URI, and the destination URI is
in the HTTP URL scheme, the value of the destination resource is retrieved.
The return message body from this method is a multipart/related, which
contains a Web Collection which describes the matching links, followed
by the contents of the destination resources.

To allow for all links on a resource to be easily retrieved, we
created a new method called GetLinks.  GetLinks returns a Web
Collection which lists all of the links defined on the Request-URI,
as (source, destination, type) tuples.

We also discussed the link search syntax, which we decided to leave
mostly as specified in the latest DAV draft.  LinkSearch is passed a
link search specification, and returns a Web Collection which lists
all of the links which match the link search parameters, as (source,
destination, type) tuples.  A LinkSearch may be performed over a
section of the URI space by specifying one or more starting point for
the link search (known as Search Points) and the depth of the
search (number of levels to search down in the URI hierarchy space).
A link search is specified using prefix notation (operator followed
by a list of operands).  Operators allowed are equals ("="), not
equals ("!="), and ("&"), or ("|"), and not ("!").  Equality
and inequality can be applied to the source URI, the destination URI,
and the type.

Also related to links are the DAV specific link types
"SupportedLinkTypes" and "SupportedLinkSchemas".  The idea of
SupportedLinkTypes is to give a location where a user-agent can
discover the link types the server will definitely allow to be created
on a resource.  Since we envision varying levels of server support for
enforcing link consistency, being listed in the destination resource
of a SupportedLinkTypes link only means that the server will allow the
creation of a link with that type.  However, the server may also allow
the creation of links with types not listed, but this is not
guaranteed.  Furthermore, the server might automatically perform some
consistency maintenance on the listed link types, but this is not
guaranteed, and is expected to vary from server to server.

The SupportedLinkSchemas link type gives a location where the link
schemas supported on the resource can be discovered. Two examples
of link schemas are "DAV" for Distributed Authoring and Versioning
links, and "DC" for Dublin Core links.

The destination of the Source link is where a user-agent can request
the unprocessed source representation of the source resource.  This
provides a way to get HTML source prior to server side include
processing, or to retrieve the source of a CGI script.

Received on Friday, 10 January 1997 21:12:39 UTC