- From: Mark Baker <distobj@acm.org>
- Date: Tue, 7 Jan 2003 01:05:01 -0500
- To: Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: www-ws-arch@w3.org
Chris, Wow, another whopper. And I thought I was bad at that! 8-) On Mon, Jan 06, 2003 at 11:43:50PM -0500, Christopher B Ferris wrote: [snip] > There has been a priori coordination... trust me. Just because it has been > fairly invisible, or has occurred gradually > over time doesn't make it any less real or any less required. That's a really good analysis, I agree with most of what you have written. There has been coordination going on in managing the complexity of various data types. > Now we are attempting to open up the space to orders of magnitude more > "types" than we have been > dealing with to date. Sort of, I'd say. More "object types" doesn't necessarily mean more "data types (schemas)" though. I assume you just mean data types. It also doesn't mean more interfaces. 8-) > Over time, we can only hope that these will become > fewer and more standardized. Or fewer and more general, which is exactly what the Semantic Web effort is about. Replacing understand-it-or-not schemas with a general data model for communicating the information within a schema, enabling partial understanding (as I described to Walden). > Beyond that, we're attempting to move beyond HTML forms, which carry all > of their semantics in the natural > language and prose which surrounds and is embedded with the <INPUT/> > elements and that requires (typically) > human intelegence to decipher, to something that can be more readily > processed by automata that > have been programmed to a specific purpose that may vary widely from one > deployed instance to another. > We can no longer rely on preconfigured availability of standardized and > standalone content handlers to > which we can dispatch the entity body of arbitrarily retrieved resource > representations. We need some means > of being able to convey/describe the details of the complete interface > (beyond the fact that "HTTP GET someuri" > will (likely) return a bag of octets as is described in RFC2616). We need > a description that includes at a minimum > the types (and hopefully some hint as to the semantics of those types) of > messages that are exchanged. Ok, we've been over that before. I think that the uniform interface is sufficient. > This brave new world is not one that REST *alone* prepares us for. Without > a doubt, there is significant > value in the architectural constraints defined by REST. I have little > doubt that from a *runtime* perspective, that > there will be significant value add for applications that adopt this > architectural style in the long run. > > However, REST does not aide in the ability for one to deploy a service > that has a prayer of being > used by a consumer that has not been written by the author of the service. Whoa, I see it as just the opposite. > <stockquote> > <company>http://www.ibm.com/</company> > <value>xx.yy</value> > <kind>http://stockstandards.org/types/realtime</kind> > <time>[assume the current time is here]</time> > </stockquote> > > Many if not most interesting applications will want to know this sort of > information BEFORE they willy nilly > invoke the HTTP GET because the only reason that they would ever do so is > to get IBM's current share price. My last response to Miles talks about this. > Or perhaps, had you similar heritage as I, the representation might > resemble this: > > <AufLageranführungsstrich> > <Firma>http://www.ibm.com/</Firma> > <Wert>80.20533</Wert> > <Freundlich>http://stockstandards.org/types/realtime</Freundlich> > <ActuelleUhrzeit>Januar 6, 2003 22 Stunden</ActuelleUhrzeit> > </AufLageranführungsstrich> > > In which case you might be scratching your head for a while trying to > figure out which way was up. > Of course, given that an HTTP GET on > http://stockstandards.org/types/realtime returns a 404 leads me to wonder > whether I really know what the devil Freundlich this set of pointy > brackets really is in the first place. Doing > an HTTP GET on http://www.ibm.com/ automatically redirects me to > http://www.ibm.com/us/ which has me very > confused. Is IBM now just a U.S. enterprise? Was I redirected there > because my browser preferences indicate > that my preferred language is en-us or is this stock price for a Web page? > Was I supposed to be doing an > HTTP GET on these URI? How did I know they were URI to begin with? These are all things an application has to deal with. REST isn't a totally free ride. 8-) Luckily what those things mean are fairly well defined in RFC 2616. If it's a 302 redirect, it means that the redirect is temporary, but otherwise semantic free. If it's 301, it means don't use the old one any more. etc.. Just as examples. > And the wert seems to conflict with what the IBM closing price was as > listed on my Yahoo Web page... > Gee, I wonder why that is? Boy, this IS an impossible mission! But that's no different than if you retrieved that exact same data via an object-specific interface. > Possibly someday we will have inference engines that can reason for, and > reprogram, themselves to adapt to > arbitrary semantics that are retrieved from HTTP GETs on arbitrary URIs > scraped off of the side of a bus or > a billboard. Perhaps someday we will have enough deployed metadata that > can be used to effect that > reasoning such that we may have little need of any a priori coordination. > Perhaps we will have RDF graphs > up the wazoo that we can leverage to give us some clue as to what resource > is identified by > http://www.markbaker.ca/9ajp23q9rj89aweruwer > > I think that that future is a long, long ways off. TimBL thinks two years. I think four. But well said, for the most part. That you're still saying that the "Web needs humans" suggests to me, as a guy who figured out the voodoo of how to use the Web without humans, that this may be the reason why you don't appear to appreciate how far forward the Web has brought distributed computing. I've tried to explain in the past how this works; in fact, the message I just sent to Walden is probably a reasonable summary. I know Mike said no appeals to authority, but I've known Roy Fielding for a few years, and he's the smartest guy I know on planet Earth. He says REST is just fine for automata. Are you *sure* he's wrong? MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Tuesday, 7 January 2003 01:04:35 UTC