- From: <janalgermissen1und1@mac.com>
- Date: Tue, 05 Sep 2006 16:41:37 +0200
- To: Marc Hadley <Marc.Hadley@Sun.COM>
- Cc: Sanjiva Weerawarana <sanjiva@wso2.com>, Mark Baker <distobj@acm.org>, public-web-http-desc@w3.org
Marc, On Tuesday, September 05, 2006, at 02:58PM, Marc Hadley <Marc.Hadley@Sun.COM> wrote: >If I might channel Mark for a moment (Mark, I'm sure you'll jump in >if I misinterpret), I think there's an unstated assumption in his >reasoning that might clarify things. AIUI, Mark believes that there >will/should only be a few standard formats in use (e.g. Atom for list- >type data, XHTML for form type data etc) and that such a constrained >world is more amenable to general-purpose processing modules, one per >format, each of which fully groks the format it is intended to >process and the semantics of data and metadata contained therein. > >Personally, even if the above turns out to be the dominant paradigm, >I still think there's utility in setting out a map of the available >resources and their supported methods and representations IMO, the right way to create such a description is to have it generated by a client that excercises the application and keeps track of the current state machine. Generating it has two advantages: it emphazises the possible instability of that information and it provides a fine impression of what the contract really is that the client can rely on (IOW: what is not runtime-discoverable or in the HTP specs must not be known). It can also show places, where additional contract is required for machine clients to excercise the application. Jan and with >APP and OpenSearch we already have existence proof that such >descriptions are useful. I just hope we can avoid a plethora of such >description languages. > >Marc. > >On Sep 4, 2006, at 4:39 AM, Sanjiva Weerawarana wrote: > >> >> Mark Baker wrote: >>> And there's the rub. In a RESTful system, that information is >>> contained within the data consumed by your application; forms and >>> links. If you *also* put that information in a document not intended >>> for application consumption, then at best you've duplicated >>> information, and at worse you've confused your clients as to what's >>> authoritative. >> >> Same battle new forum .. hi Mark ;-). >> >> I don't understand you at all - so its ok to put the info in >> English (or Korean or Sinhalese) but its not ok to put it in XML in >> a machine processable format?? >> >> Do you think that (obviously crazy) programmers don't read English >> (or Korean or Sinhalese) and *couple* their programs to the >> services thus described? Or do you think that because you don't put >> it down in XML that they hand write magic self learning code that >> can handle any change in the data dynamically? >> >> Its easy to do this stuff when there's a smart agent like a human >> in front of course. When there's no human in the loop the problem >> is a just a tad harder. >> >> Sanjiva. >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >> email: sanjiva@wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000 >> >> "Oxygenating the Web Service Platform." >> > >--- >Marc Hadley <marc.hadley at sun.com> >Business Alliances, CTO Office, Sun Microsystems. > > > > ------------------------------------------------------------ Jan Algermissen http://jalgermissen.com Software Architect http://www.tugboat.de
Received on Tuesday, 5 September 2006 21:00:34 UTC