Re: Binding

Mark Baker wrote,
> > Let's not muddy the waters, and keep the interaction as is.
>
> I wouldn't call it a "discovery" phase.  It's just the first link
> traversal, where the data returned happens to describe URI
> structure, and binds known terms to URI parameters - exactly the same
> thing that an HTML GET form does, only not for humans.

Fine, in which case it'd have a similar form to the response in 2', so I 
don't think it'd make any difference one way or another.

But I'm not interested in discussing this in the abstract. If you want 
to extend that interaction backwards, illustrating client requests and 
service responses (feel free to introduce as many additional services 
as you like) then please do and I'll comment further.

FWIW, I think it would be just more of the same, and in fact would 
illustrate that yet more shared context, knowledge and expectations 
would be required ... eg. between the client and whatever service is 
supporting the discovery.

> > That doesn't change things materially. The element name could be
> > spelt "uri" or "quote" or "sdjkfsdfsk". What matters is that the
> > client knows that at this point in the interaction the URI will do
> > something useful for it.
>
> Yes, but - and I admit I've done a poor job at explaining this - the
> "a priori" information we're talking about here for the RESTful
> approach is just the same a priori information needed to understand a
> schema. There's nothing else that is needed - check above.  With
> WSDL, you need the a priori information of how to process the schemas
> in use *and* the a priori information of the interface to that data.
>
> Do we agree to that last point, even if we may not agree on the
> impact to the properties of the respective architectural styles?

Absolutely not.

I assume that when you say "schema" you mean it in the sense of DTD, W3C 
XML Schema or RelaxNG.

I'm afraid this is just wrong. Given a URI and a schema and just generic 
URI and schema handling code, the _only_ things you can do are generic 
URI and schema things ... ie. nothing much beyond dereferencing and 
validation.

That's not sufficient for a client that's supposed to act as a result of 
dereferencing a URI (unless the possible actions are merely to 
dereference more embedded URIs, in which case we're back in spider 
territory).

> Another way of looking at this, if you squint a little, is that
> spiders don't have to be very general things like search engines, or
> maintenance bots.  I could write a resumé collection and analysis
> spider who invokes GET willy-nilly in its search for HRXML based
> resumes.  If it doesn't find one behind a URI, it simply moves on to
> the next URI in its queue that it earlier discovered.  The only a
> priori information required there is the ability to spot URIs in
> arbitrary content.

Ahh ... we _are_ back in spider territory.

There may very well be an interesting class of distributed systems which 
can be modelled as dumb spiders. But I think you're missing (at least) 
two very important points.

First, you're ignoring the fact that anything more sophisticated than a 
simple link follower has to be able to make choices about _which_ links 
to follow if there are more than one in any given returned 
representation.

It's noticeable in this thread and elsewhere you're particular fond of 
examples where for the spider/client there's only one transition onward 
possible from any given resource (in which case you substitute 
redirects for URIs in response entities) or where there are several but 
all are equally acceptable, or where there are several and all of them 
should be followed.

But often that simply isn't the case ... for example, response 2' in the 
interaction I illustrated earlier where the client has to choose 
between two onward links, "buy" or "sell", depending on its goals and 
constraints (three if we include the "no deal" reaction which would 
terminate the interaction at that point). The ability to make a 
meaningful choice implies prior knowledge, goals and constraints. Not 
only can these not be magic'd away, they're the very things which drive 
the interaction forward.

Second, if a dumb spider is going to produce interesting and useful 
results from wandering around a network, that implies that the network 
itself must have some interesting and useful properties. That's true in 
the case of the Web due to the fact that it's been constructed 
piecemeal over more than a decade by millions of human authors whose 
linking behaviour encapsulates vast amounts of information. It's 
because of this that, eg., Google's bots are able to produce 
interesting and useful results from their wanderings: they're 
essentially parasitic on the prior activities of publishers.

Spiders on the Web can only answer certain kinds of questions (eg. is it 
likely that the resource with some URI relates to "marmalade", or are 
the two resources with these two URIs likely to be related to the same 
topic). If you want a spider to be able to answer different kinds of 
questions, you have to design a different kind of network for it to 
traverse. Any such network and it's corresponding URI space would also 
encapsulate prior knowledge of some sort even if the spiders that 
trundle over it are pretty dim. In fact it's _because_ that network 
encapsulates prior knowledge that the spiders _can_ be dim.

In which case, of course, it's entirely wrong to focus solely on the 
(lack of) complexity in the spiders. The a priori knowledge is encoded 
in the network, and the work involved in creating the network has to 
counted if you want to make a fair comparison with other approaches.

As such, I don't think you'll be surprised that I find your earlier 
response,

> The structure of URI space is *completely* irrelevant, because the
> service creates the URIs, and clients use them opaquely without any a
> priori knowledge of what each one is; the a priori knowledge is in the
> code that interprets the schemas and understands what it means for
> some token, such as a URI, to be in a particular place.

completely unnacceptable.

> > And we agree that all this was by prior setup at the service end,
> > and that the nature of the service provided corresponds to the
> > hard-coding on the client end? Good.
>
> There's degrees of "corresponds".  I think you believe it corresponds
> very closely.  I believe it "slightly" corresponds, or in other
> words, it's not coupled any more than it needs to be to get the job
> done, viz a viz the form issue above.  I believe the use of WSDL is
> coupled much more tightly than that.
>
> So depending what you meant by "corresponds" ... 8-)

I mean "corresponds" in pretty much the same sense in which the code of 
an HTTP client corresponds to the code of an HTTP server (rather than, 
say, the code of an FTP server) ... ie. the execution of the code at 
the endpoint results in the correct execution of a protocol.

I'd like to know more about what you mean by "slightly", and what metric 
you're using which allows to you to say that WSDL is "more tightly" 
coupled.

Cheers,


Miles

Received on Wednesday, 8 January 2003 05:17:29 UTC