Re: Translation in the Tower of Babble

Well the bottom line is whether or not Geoff is interested in using such a
model ;-)

--Eric

----- Original Message -----
From: "Yaron Goland" <yarong@Exchange.Microsoft.com>
To: "'Eric Sedlar'" <esedlar@us.oracle.com>
Cc: <w3c-dist-auth@w3.org>; <gclemm@atria.com>
Sent: Monday, January 03, 2000 6:00 PM
Subject: RE: Translation in the Tower of Babble


> Actually I started down the path of trying to write a general model for
> WebDAV in
> http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0020.html but
> no one seemed really enthusiastic about the project.
>
> > -----Original Message-----
> > From: Eric Sedlar [mailto:esedlar@us.oracle.com]
> > Sent: Monday, January 03, 2000 4:09 PM
> > To: Yaron Goland
> > Cc: w3c-dist-auth@w3.org; 'gclemm@atria.com'
> > Subject: Re: Translation in the Tower of Babble
> >
> >
> > Yaron,
> >
> > The problem with discussing abstractions like this without
> > concrete examples is
> > like trying to write legislation without loopholes--you don't
> > really know if
> > it's well written until you see its effects.
> >
> > My guess is that the direction you are heading in is defining
> > a resource as the
> > base class of all WebDAV objects capable of responding to an
> > HTTP request.
> > This is a good abstraction.  It follows from this that an
> > HTTP method like LOCK
> > should not apply to a URL that does not identify a resource,
> > since there is no
> > resource to respond to the request, which would outlaw the
> > lock-null approach.
> >
> > It might be useful to give more of an "agenda" for where this
> > thread is going
> > (even without filling in the details), so people can better place your
> > discussion in context of the world of WebDAV problems.
> >
> > In general, however, I think that any solution to the locking problems
> > discussed recently has to fit in some general model like the
> > one I anticipate
> > that Yaron will propose.  However, I prefer a complete model
> > to be laid out
> > before me before I comment on particular precepts of the model.
> >
> > For example, following this level of abstraction, we should
> > define a resource
> > better.  I would say that a resource has a set of properties,
> > which can be
> > represented via an XML document.  Some of these properties are
> > "live" properties, which are read-only and are set as a side
> > effect of other
> > methods ( for example a modification date).  Attempts to set
> > the value of a
> > live property directly via generic property mutator method(s)
> > (e.g. PROPPATCH,
> > PUT, etc.) should always be ignored.  A collection is a
> > subclass of resource
> > that has a live property containing a list of tuples
> > including at least a name
> > (and possibly with other values such as a resource ID
> > associated with that
> > name).  A BIND request is treated as a method that modifies
> > the values of the
> > collection's name tuple list.
> >
> > This should all be worked into the versioning model document
> > (http://www.ics.uci.edu/pub/ietf/webdav/versioning/model990209
> /), which while
> defining some of the functional methods available on a resource, doesn't
> define
> the properties on a resource as well as a number of the other assumptions
> along
> the lines Yaron proposes.
>
> --Eric
>
>
>
> Yaron Goland wrote:
>
> > I believe that there are too many different unstated assumptions held by
> > members of this group for this group to be ready to deal with specific
> > locking proposals. The fact that Geoff, Eric and RFC 2518 can come out
> with
> > such different proposals helps to illustrate the issue. Rather than
> > attempting to achieve consensus in one fell swoop by having everyone
read
> > and critique full proposals I would suggest that we start from a simpler
> > basis. Let us first see if we can establish agreement on some very basic
> > precepts. I will start with just one precept and see if we can get
> agreement
> > on just that.
> >
> > Precept #1 - HTTP clients send HTTP request messages to resources that
> > respond with HTTP response messages.
> >
> > Corollary #1.1 - All HTTP proposals can only be written in terms of how
a
> > resource processes a HTTP request from a HTTP client and generates a
HTTP
> > response as a result.
> >
> > Corollary #1.2 - HTTP requests do not necessarily have to be handled by
> HTTP
> > resources. For example, it is possible to send a HTTP request with a FTP
> > request-URI. Some HTTP proxies are set up to act as gateways that can
> handle
> > translating the HTTP request into a FTP request and then translate the
FTP
> > response into a HTTP response. That is why precept #1 states "...to
> > resources..." rather than specifying a HTTP resource.
> >
> > Corollary #1.3 - Since HTTP request messages can only be handled by
> > resources which respond with HTTP response messages then even error
> messages
> > such as "Not Found" must have been generated by a resource.
> >
> > Let's see if we can just get agreement on this single precept and its
> > corollaries.
> >
> >         Merci,
> >
> >                         Yaron
>

Received on Wednesday, 5 January 2000 04:41:54 UTC