RE: Design Team Notes: Links/Attributes/Metadata

Some points of clarification:

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)
#2 does require negotiation as you could negotiate on what kind of
anchor is returned. Which, ultimately, lead to the proposal being turned
down and #1 picked in its favor. Especially when it was pointed out that
anchors rightly belong in URIs as they point to the exact location of
information, just because that happens to be inside of a document does
not decrease generality.

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 destination URI does not have to be in HTTP, it only has be
retrievable by the server. So if the server is able to retrieve FTP
requests and then package the result in HTTP, that would be fine.

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.

The GetLinks method allows for better definition then the paragraph
would lead the reader to believe. It provides for the same specification
of source/destination/type as provided in GetLinkVal and allows for
wildcards.

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.  

Of course the listed types are subject to access control. Just because a
link type is returned in the list does not mean that the user is
authorized to create that type of link.

		Yaron


>-----Original Message-----
>From:	Jim Whitehead [SMTP:ejw@rome.ICS.UCI.EDU]
>Sent:	Friday, January 10, 1997 5:30 PM
>To:	w3c-dist-auth@www10.w3.org
>Subject:	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 Saturday, 11 January 1997 01:18:40 UTC