RE: Hierarchical URLs and Collections

One of WebDAV's primary goals was to bring order to the HTTP URL's
hierarchical nature. That is, HTTP URLs have used these "/"s which were
meant to denote hierarchy but there weren't any rules regarding what the
hierarchy meant. Simple things like "If /a/b/c exists does this mean /a/b/
exists?" weren't specified. So WebDAV specified them.

Creating a flat namespace, on the other hand, requires some fairly
sophisticated protocol elements if one is to provide clients with the
capability to not just read but also to manipulate the namespace. The reason
that flat namespaces require sophistication is that one can not leverage the
implied semantics provided by a hierarchical namespace.

That is, if I create a resource called /a/b/c then we can specify that "c"
MUST appear in "b" which MUST appear in "a". That is, all the relationships
between the resource and all related resources are implied directly from the
resource's name. This makes for a simple protocol.

Flat namespaces, on the other hand, require explicit declaration of all
relationships. This means that every resource must be able to declare both
who its children are and who its parent is. Even that is not sufficient
since most flat namespaces actually represent DAGs (in fact, some are just
DG since they allow cycles) thus a resource could have multiple parents as
well as multiple children. In order to allow an interoperable interface to a
flat namespace store it would be necessary to provide protocol elements
which allowed for the atomic assignment of relations as well as a format to
declare the current list of relations.

These requirements should sound extremely familiar to anyone who has been
participating in this group for any period of time. They are almost
identical to the requirements for versioning. You need to create a
versioning graph. You need to allow distributed alterations to the graph.
You need to be able to read the graph.

I have often said that we need to view our versioning effort in a wider
context. What we are really creating is a set of protocol elements which
allow distributed editing of a state graph which contains typed links. Those
links could be "parent", "child", "version of", etc.

As such I encourage the various document vendors who need a flat namespace
to involve themselves in the DAV versioning effort and to ensure that the
commands and properties created by that effort are sufficiently versatile to
allow for arbitrary state graph manipulation.

		Yaron


> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tuesday, August 18, 1998 9:13 AM
> To: 'WebDAV'
> Cc: Falkenhainer, Brian; Garnaat, Mitchell
> Subject: Re: Hierarchical URLs and Collections
> 
> 
> Brian summarized his original issue to me very succinctly 
> this morning:
> 
> WebDAV equates semantic containment with syntactic 
> containment in a URL
> path.  It assumes that any semantic containment relationships will be
> reflected in the URL path.  Document repositories typically 
> do not make
> this assumption.  
> 
> In fact, repositories strongly prefer not to make this 
> assumption.  They
> don't want to use location as a means of referring to objects they
> control, since location can change; they want to use an 
> identifier that
> is guaranteed not to break.
> 
> What we need to assess is whether making the assumption that semantic
> containment is reflected in the syntax of the URL has caused 
> any serious
> problems in WebDAV.
> 
> Jim Whitehead pointed out that document repositories can 
> still construct
> valid WebDAV URLs that separate semantic containment from the 
> URL.  They
> simply show a flat namespace to the world in the URL, and maintain the
> containment relationships separately.
> 
> John Turner has also pointed out that the repository can map its flat
> namespace into one that embodies the semantic containment 
> relationships
> in URLs.  This practice presumably is offensive to repository 
> designers
> who so carefully avoided it in developing their products.
> 
> Do clients care whether the URL embodies semantic containment
> relationships or not?  Presumably not when they are 
> navigating downward,
> since they will use PROPFIND to do that.  But if they want to navigate
> upward in the containment hierarchy, WebDAV provides no 
> standard way to
> do so except by parsing the URL.
> 
> I suspect this is an oversight in WebDAV that may have resulted from
> assuming containment relations would be visible in the URL syntax.
> Unless it can be remedied, it means that repository vendors MUST
> construct URLs that show the semantic containment relationships.
> 
> -- Judy
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>

Received on Tuesday, 18 August 1998 15:38:05 UTC