Re: section 1, intro, for review

> You may or may not be correct about that.  Presuming you are, then I think 
> you are arguing that the URI Identity document [1] should call out REST as 
> integral to the web architecture.

Yes, I commented on this[1].

But note that the "HTTP URI scheme" is not forever only usable by the
HTTP protocol.  Any protocol built to REST can access and manipulate
anything with identity, which of course includes all URI using the HTTP
URI scheme.

>  To use HTTP as a placeholder for REST 
> does not seem appropriate to me. 

Agreed, modulo my comment above.

> Which raises the question, should REST be called out as fundamental in 
> dealing with URI's?  The proposed URI document [1] quotes RFC 2396 [2]:

I believe it could, yes.  Whether that needs to be in section 2, or
elsewhere, I don't know.

> >> "Any information that can be named can be a resource." 
> 
> and then goes to some trouble to point out that non-electronic resources 
> such as people are certainly included, and that one can even speculate on 
> URI's for such ephemeral notions as "love".  I like that. 
> 
> I don't think I want to GET or POST my love, or even necessarily a 
> representation of it.

Without getting too mushy, a GET on love could return a poem, pictures
of your family, etc.. anything you believe best represents love to you.
I'm not sure how I'd interpret the mutability of love though.  8-)

>  Load/Store or Get/Put is a compromise for many 
> electronic resources as well.  The operations I want to do on an incoming 
> video stream may be "slow down", "cut frame rate", "switch to black & 
> white" or some such (suggesting that http is indeed not the last protocol 
> we'll need).  So, I see some conflict between restricting the Web to REST, 
> and allowing the Web to embrace all that can be named. 

REST suggests that you can build extended agreement over the wire if it
can be generalized for all resources.  Conceptually, your example could
be implemented with a form of runtime content-negotiation, perhaps with
a set of media features.  Practically though, I can't see using HTTP for
it, because I can't see how you'd extend pipelining and/or chucking to
implement it.  But certainly a new REST based protocol that placed an
emphasis on streaming could be designed to do it.

> I do think that REST applies well to the many resources that are well 
> modeled as memory stores.  By that I include web documents, etc.  I even 
> see the value of stretching a common REST model to borderline cases. 
> Still, to say that the web encompasses "everything", but that as a 
> consequence everything looks like a computer memory (or maybe the I/O 
> ports on a computer bus), seems much too limiting.

It might seem that way.  Perhaps we need some more examples to chew on
to test the limits.  I know there are limits, I just think they're
fringe.  On the other hand, what most people are attempting with Web
services appears to suggest that they believe there are a wide variety
of mainstream information processing tasks that cannot be fit into
the "information space" model.

> Speaking of which, one of my few quibbles with [1] is it's presumption 
> that most resources have or are "values".  For example [3]:
> 
> "The important point to note is that in general a resource is a time 
> varying mapping to a value."
> 
> Whether my love has value is an interesting question.  Seriously, this 
> conflicts with the universality of the web.  The resource that is a person 
> is not well modeled as being or having a value.

IMO, it's just "state", i.e. what is the current state of your
definition of love?  Perhaps that changes over time.  Maybe you want to
add chocolate cake (hey, there's a good POST example 8-).

 [1] http://lists.w3.org/Archives/Public/www-tag/2002Mar/0049.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Monday, 18 March 2002 23:21:22 UTC