Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Re: Why REST? (RE: WSIO- With Name)
 Then we are solving different problems. You are interested how a thing is named. I am interested in establishing a tightly organized protocol of interactions, and in this, one that is recognizable to humans. I have to get past a Google-like search to a registry precisely because the first sort of membership should be done by people. Even if humans are "sticky" they are much better at discovery and recognition than computers so we need a system that attempts a subset of what humans do, not one that tries to improve on them. Shirkey is blind to the obvious, as many programmers are in this regard: we automate to augment, not replace human intelligence. "At best, XML makes it possible for businesses or developer groups to share data, provided they agree on the semantics of that data in advance. This is not to say XML is not an enormous advance. It plainly is. However, its advance lies in aiding data interoperability where shared semantics can be assumed. It does nothing at all to create semantic interoperability." Duh. Data is portable. Systems interoperate. It is the system of messages that preoccupies me and I think possible Michael and others who have to do CRM systems and their like. It is the system, not the address. A protocol systematically organizes the exchange of messages that are reproducible at *both* endpoints. Protocols don't guarantee semantics. Yes, we organize in advance and negotiate out the noise. "Shared context has to come from somewhere, it can't simply be defined into existence." Yes it can. It is negotiated into existence every day. That is what contracting is all about. I do agree that there is a level at which the UDDI and WSDL yield to document types and document types to local fine-grained processing, and this to human inspection, verification, and sign-off. He says it: "Where Web Services work beautifully, however, is where the parties involved already agree about interesting things and already have a framework for cooperating or collaborating." Ummm... Clay fella, regardless of hype, "friction-free" means someone oiled it. I don't think web services will be useful for things much deeper than that. That is why the promotion of fine-grained services seems a bit *wonder full* IMO. Reliability enters the picture and the 404 isn't acceptable. But having predefined ports and exchanges of common document types is PRECISELY what we need to be able to work in markets where our business partners build part of the system (one application) and we build another. Otherwise, dammit, we HAVE to give it up to Microsoft. If this is all coming down to commodities, they are going to win because there isn't enough profit there for anyone selling less than a million copies a record. Look at what digital technology has done to the recording industry. That is our future. len -----Original Message----- From: Paul Prescod [mailto:paul@p...] I don't claim to have magical solutions to these problems. I keep plugging away at the same old, painful solution I've been plugging away at for years: standards. We've got a standard application protocol. In the context of REST: we've got a standard application protocol. It does what we need. Reinventing a *less* expressive protocol like SOAP-RPC is both a step backwards and a waste of time. Inventing domain specific XML vocabularies like widgetML -- now that's a step forward! Seriously. If you want a registry for businesses I would suggest you use Google or Yahoo. If you want to look up businesses by NAICS code, I'd suggest you ask Google (or Yahoo) to implement that. They knows a lot more about making useful search engines than web services people do. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
