[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" wrote:
>
>...
>
> Precision. Discovery. Google is only as good as I am able to cognitively
> recognize a precise term, a precise message to send which it will interpret
> as a request. Otherwise, I get a few to a few thousand candidates back.
As I said before, I have no magic bullet for discovery. But here's what
I will say: when Google returns you a thousands links you will know that
all of them support between one and four methods: GET, [PUT, POST,
DELETE]. And some of them will be in XML vocabularies you don't know
about. Those are useless to you, just as SOAP interfaces you don't know
about are useless to you.
But some of them will be in XML vocabularies you DO know about, and they
will have hyperlinks to other documents and those will have between one
and four methods called GET, [PUT, POST, DELETE]. And iteratively, some
of those documents will have hyperlinks to OTHER documents and etc. etc.
This transitive closure of documents is called a Web. And in fact Google
uses this Web to build up its index. It is a component that depends upon
the REST structure of the Web.
An RPC interface does not have this property. At best Google can return
a hyperlink to an end-point and human readable documentation about how
you could write a Python program to access the data behind that link.
But Google can't read the human readable documentation so it can't
follow that hyperlink. That service is a black-box to it. And even if it
might have been useful to you as a human being, the chances are good it
won't have an interactive interface either, because interactive
interfaces are not trendy and cool like machine-to-machine interfaces.
And buiding interactive interfaces on RPCs is harder than building web
pages on top of XML resources, so people probably won't usually body.
>...
> It's a document, packed in a URI or in the body, it's a document.
Don't know what you're talking about. Is a filename a document in and of
itself? If you want to say so, you can say so, of course. I could also
say: "it's all bits" and it is about as illuminating. The identifiery
for the thing is useful in different contexts than the thing itself is.
The URI is just the identifier.
> I'm not so sure Fielding did much more than the genCode and GML
> guys did in recognizing that documents are how humans formally
> communicate instructions (ok, gestures, speech acts, etc. but
> these are bits on the wire with character encodings, so, docs).
I don't think Fielding did more. He did different. Protocols and markup
languages are quite different. Very different constraints.
> >There's nothing wrong with packing an XML file in a POST. XML is just a
> >syntax for a message with some semantics.
>
> It's a syntax until the right interpreter interprets it according to
> the local semantics. URIness is just address space. Until it is
> associated to a type (you like MIME), it is meaningless.
URIs do not have MIME types.
> >You go wrong when you start to
> >mismatch the semantics with the Web's natural data model, which is
> >resources, URIs and representations (i.e. REST).
>
> Ummmm... REST = Document. Otherwise we are just overloading
> function names. If we do that, why not just use functions
> (what UDDI does).
???
> >Putting the parameters in the URI makes the query
> >addressable.
>
> It means I write the query's name next to its address on the
> front of the envelope.
They are part of the same thing. They aren't beside each other. They are
a single referencable unit. "Len Bullard in Austin".
> >> But not FTP. FTP let's me get and set directories, change file names, delete files,
> >> and so on.
>
> >HTTP also. DELETE deletes files. GET and PUT renames them (though there
> >is an HTTP extension called MOVE which is an optimization). Getting and
> >setting directories are primarily a convenience for interactive use.
>
> Convenience may be at the heart of UDDI. Is there anything wrong
> with convenience?
UDDI is profoundly inconvenient because components within it are not
addressable and cannot be used within XSLT stylesheets or RDF assertions
or XLink links. UDDI is only convenient to Java programmers.
> ... Seems to me we accepted a lot of retrograde tech
> to get the convenience of universal addressing.
Universal addressing isn't a convenience. It's an architectural decision
that allows some applications that would otherwise be impossible to
build.
> ... I don't particularly enjoy
> stateless programming. It's a pain in the neck and not very fast. ;-)
Why would you do stateless programming? The Web doesn't demand it of
you. Most Web programmers don't do stateless programming.
> >URIs are so much more flexible than the siloed naming schemes
> >available in those protocols.
>
> Flexible or just won based on a momentum that then hit a brick wall
> of economics.
I'm surprised that you think that the flexibility of URIs is really open
for dispute. These URIs address resources about as diverse as possible
to imagine:
http://www.google.com/search?sourceid=navclient&q=Len+Bullard
http://www.britneyspears.com/home/index.php
http://www.careercenter.arlington.k12.va.us/video/pyth24min.mpg
http://www.expedia.ca/pub/agent.dll?qscr=fstr&itid=34958964&bkmd=2&zz=1013489956491
The first is the set of all documents on the Web indexed by Google that
mention Len Bullard.
The next is the home page for a pop star.
The next is a movie about how the Python programming language brought a
young couple together.
The next is the middle of a transaction to buy airline tickets.
How much more flexible do you expect URIs to be?
> ... We don't want to throw the baby out with the
> bathwater, but saying "on The Web" sells exactly nothing these
> days. In fact, it raises suspicious eyebrows (which is why
> you are being put through this grilling). I agree that a universal
> address space has advantages, but really, that is DNS for this
> system. URIs are a way to put an application on the top of that
> based on naming conventions and letting HTTP be the proxy master.
> If MS had proposed that originally, most of you would still be
> using FTP and WAIS.
Ummm. Okay. It works. That's all I care about.
>...
> That is a literal email client. The point is the problem of the
> a priori agreements based on discovery. UDDI says that discovery
> should be quick and precise, dedicated not to generalized search,
> but to registries of business types with precise commands for
> drilling down to get the stuff you want when you want it.
That's not how it works. UDDI advocates may wish it did, but it does
not.
>...
> Very true. Discovery is what UDDI cares about. It is what the user
> cares about. REST is another way to say, at this address
> (if you know this address) is a document that tells you
> the state of this resource at this time. UDDI is "in accordance with
> the conditions we have agreed upon to this time". I need to understand
> how all of the rest of that is done because an address
> is not enough. In most cases, a name is not enough.
No it isn't. You also need XML vocabularies and busines processes that
you know about. The only question is whether to layer on yet another
layer of interoperability issues in the choice of method names and
addressing spaces. I claim no, we should solve interoperability problems
whereever we can and then move on to tackle other ones.
Paul Prescod
|
