Lists Home |
Date Index |
"Bullard, Claude L (Len)" wrote:
> 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.
Google is a registry.
So is Yahoo. Registry was Yahoo's first business.
>... 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. 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
> 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.
> ... 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.
> "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.
"The goal of the UDDI Project is to offer the basic infrastructure for
dynamic, automated integration of all e-commerce transactions and Web
> 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.
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.