RE: Structured Resources

The URI namespace is flat. The URL namespace is not. Any URL can be
decomposed into a base and an extension. This provides the mechanism to
build up hierarchies. This hierarchy also provides the mechanism to
present arbitrary structure. This makes Mr. Woodhouse's mime multipart
extensions unnecessary as the same hierarchical structure can be built
with URLs. However another mechanism will be necessary for more generic
URIs. My recommendation, given that currently the only URI widely
deployed is URLs, is that we adopt the PUT convention for URLs and leave
the definition of a more generic mechanism for URIs to a future group.

As for the meta-data, I was thinking along the lines of HTTP headers,
which includes the ultimate arbitrary meta-data mechanism, links.

As for orderings other than hierarchies, one can always add a header
specifying that ordering and the new entry's position within it. For
example, if one is recording a list of postings to a discussion group
one may wish to order based on posting date, reference, and title. So
when a new post is added to the structure, it will include the previous
data as meta-data. I will be proposing a mechanism to allow for the
generic addition of meta-data either tonight or tomorrow. I have already
written up the proposal, I just need to proof read it. This data is then
presented in the structure thus allowing the client to determine the
proper ordering. I will also be introducing a sort header to allow the
client to explicitly indicate how it would like its results sorted.

I hope that clarifies things.

	Yaron

> -----Original Message-----
> From:	Terry Allen [SMTP:tallen@sonic.net]
> Sent:	Monday, March 17, 1997 6:51 PM
> To:	w3c-dist-auth@w3.org; Yaron Goland
> Subject:	Re: Structured Resources
> 
> Yaron Goland writes:
> | Documents have structure and it would seem a good thing for DAV to
> | expose this structure and make it available for manipulation. As
> such I
> | propose a new Method, STRUCTURE. When executed on a resource this
> method
> | will return a description of the structure of the document.
> 
> This suggestion touches on points of interest in several other
> contexts.
> Partly with those contexts in mind, a few requests for clarification:
> 
> | I recommend that the structure of a resource be expressed as a list
> of
> | URIs, some relative, some not, along with associated meta-data. The
> | STRUCTURE method returns this list.
> 
> How does the (flat?) list of URIs map to the structure of a document
> that can be in any arbitrary format?  By the metadata?  What is the
> format of the metadata?
> 
> | One method for adding to the structure of a document is to PUT a new
> | resource, where the request-URI has the same base as the structure
> | resource. Thus if the structured resource is http://foo then
> | http://foo/bar specifies a member of foo's structure.
> 
> How is the relationship of bar to other members of foo indicated, and
> in what context?  If I PUT a bar, how does my interlocutor know where
> in foo bar should go?  Would I not have to PUT bar plus at least an
> outline of the new structure of foo, as modified by the addition of
> bar?
> 
> 
> Regards,
>   Terry Allen    Electronic Publishing Consultant
> tallen[at]sonic.net
>        specializing in Web publishing, SGML, and the DocBook DTD 
>                    http://www.sonic.net/~tallen/
>   A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Received on Tuesday, 18 March 1997 01:38:41 UTC