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 ]


<ack>Lyrics from Springsteen</ack>

From: Paul Prescod [mailto:paul@prescod.net]

>Google is a registry. 

Then I need to be more specific:  I need a registry of businesses 
of a type (first, and yes, Google can offer that service).  Then 
I need a registry of services (and they can do that too).  But 
eventually, I want to hook my services to the services I discover 
and let them run as much as possible on their own.  I may not want 
Google in that loop anymore than I want a car salesman to be 
my chauffeur.

>>... Shirkey is blind
>> to the obvious, as many programmers are in this regard:  we
>> automate to augment, not replace human intelligence.

>Shirky isn't blind. He was responding to the prevailing rhetoric of the
>day that human beings would not be needed. 

Yes, that's dumb.  I'm not any more impressed by it than I 
am by the Semantic Web.  Golems.  Still, there is enough baby in 
the API bathwater for things we need to do.  

Is this just an argument over GUIDs vs URIs?

"I want to read your mind to know just what I got in this 
new thing I've found..."

>If the goal is to make
>something that augments human searching then I'll mention again that
>Yahoo and Google have a lot more experience than the UDDI people. And it
>shows.

>http://uddi.microsoft.com/details/businessdetail.aspx?businesskey=344d5d11-069e-4f6c-8f83-e0f370413505

It substitutes ontology a priori over groping through inexact search terms, but you are right, 
it isn't any fun the first time.  In either interface, there is no substitute for training 
except dumb luck.  Apriori vs apriori.  But this isn't a URI thing; it's a knowledge thing.

"We stood before the altar.  The gypsy swore our future was right."

>> 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.

>Linking and addressing is the best tool for managing the complexity of
>the system. You're an old hypertext guy. This should come as second
>nature to you.

"God have mercy on the man that doubts what he's sure of."

It does and I am old.  Old enough to have recognized that a link and 
a function call aren't that different at the end of the day.  And old 
enough to know that most of what the hypertexters wanted (except for 
a system for uniform addressing on the internet) was had in the 
Macintosh GUI.  HTML was leap backwards to accommodate the aging 
Internet tech that DoD cast on the waters in 90/91.  We went back to 
go forward at scale.  Scale is achieved.  Next we want to do something 
a bit more like a message switch and a bit less like a telephone book.  

>> ...  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.

>And when you are done sending back and forth the messages and the
>auditor comes to you and asks what is the state of the system? You point
>him at an address. And if the auditor is to ensure that both partners
>have the same view of the transaction, they'd better have a shared set
>of addresses or at least links.

"well I tried so hard baby, but I just can't see
what a woman like you is doing with me."

Ok at the highest level but once we get down to what my system actually 
does when that message is received, it's local. 

>> 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.  

"Now look at me baby, struggling to do everything right, and then it all 
falls apart..."

>"The goal of the UDDI Project is to offer the basic infrastructure for
>dynamic, automated integration of all e-commerce transactions and Web
>services."

Like Kay asked me about the statement that namespaces are only for 
disambiguation, "and you believed that?"

>...
> 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. 

"I want to know if it's you I trust, cause I damm sure don't trust myself"

>That's just what I said.

>We need common vocabularies. The only question is whether we also use a
>common addressing model for addressing our documents, or an infinite
>number of proprietary addressing models, one per web service.

So we have the nut of this.  Definitely not the latter if we are 
in a hurry to do common things by common means. 

"So when you look at me, you better look hard and look twice...
Is that me baby, or just a brilliant disguise.."

len




 

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

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