OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Re: Why REST? (RE: [xml-dev] WSIO- With Name)

[ Lists Home | Date Index | Thread Index ]

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@prescod.net]

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.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS