W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Binding

From: Mark Baker <distobj@acm.org>
Date: Tue, 7 Jan 2003 00:09:46 -0500
To: Walden Mathews <waldenm@optonline.net>
Cc: www-ws-arch@w3.org
Message-ID: <20030107000946.B26567@www.markbaker.ca>

Hi Walden,

On Mon, Jan 06, 2003 at 09:52:22PM -0500, Walden Mathews wrote:
> Mark,
> > For example, assuming that a URI was tagged with "ibm-related-things",
> > then an app written to grab and analyze stuff related to IBM would
> > want to recognize that element and invoke GET on the URI.  A wide
> > variety of forms of data could be returned for analysis, including
> > data that doesn't have anything to do with IBM; a runtime type
> > error (which should indicate that binding is still late).
> > 
> In other words, "ibm-related-things" is a partial specification, leading to
> immediate partial understanding, which can be developed into full
> understanding by the coordinating applications if the ROI warrants
> that, and the ROI calculation can be performed at runtime, not design
> time, but actually at either time.
> Comments?

Heh, I thought about getting into partial understanding, but avoided
it.  But no, I wouldn't say this enables partial understanding, since
understanding "ibm-related-things" is an all-or-nothing proposition.
In order to enable partial understanding, you'd need a shared data
model that could describe what an "ibm-related-thing" is in
terms of other things which may be known (dare I say "RDF"?).

> So when the app does GET on the URI, it gets something it wasn't
> anticipating, and then has to make sense out of that.  But not necessarily
> complete sense.  It can weed out irrelevant content based on some
> heuristic.  The remaining question is: when the app wants to do something
> other than snoop around, how is the understanding gained?

As above, it's gained by having it be related to other things, some of
which may already be known (and having already deployed enough general
stuff that everything can be related to like RDF, RDFS, DAML, OWL).

For example, if our IBM-analyzing app knew that
"http://foo.org/relatedTo" meant "related-to" (i.e. it was hardcoded
to know that) and ran across an RDF SPO triple;

<http://www.sun.com> <http://foo.org/competitorOf> <http://www.ibm.com>

It might see that IBM was the object, but not recognize the predicate.
So it could do a GET on it to discover a triple like this;

<http://foo.org/competitorOf> daml:subClassOf <http://foo.org/relatedTo>

(where "daml:subClassOf" is presumed to be known since it's part of
DAML, and means sub-class-of as you'd expect)

This tells the client that the "http://foo.org/competitorOf" predicate
can be treated as if it were "relatedTo".

The client could then conclude that http://www.sun.com identified a
resource which was related to IBM, and report that in its analysis,
even though it doesn't know what a competitor is.  And that's just the
simplest form of partial understanding.

>  How does
> that differ from the WSDL method?  How "late" can WSDL be bound?

WSDL describes interfaces.  It can describe interfaces which are used
in a late bound scenario, no problem.  What that entails is defining
an interface which doesn't map directly to the interface of your
application objects, i.e. it provides an abstraction.  Clients
couple to this abstraction, deferring the determination of which
application object and method gets invoked until runtime.

So there aren't "degrees of late binding", but there are degrees of
generality of the abstract interfaces used in late binding.  For
example, the Shape[1] abstraction is wonderful for dealing with
shapes of all kinds, but it can't easily be used (well, had I done a
better job and populated it with more shape-specific methods 8-) for
other stuff that aren't shapes.

> Is there some limit where both approaches converge?

I don't believe so.

>  Is the benefit of
> late binding to be expressed just in the tightness of feedback loops, or
> something else?

Not sure what you mean by "feedback loops", but I might express the
benefits in at least a couple of ways;

- reuse; the more general the interface, the more extreme the reuse,
and the more intense the network effects, since more objects can be
accessed with it
- low coordination costs via the ability to bind an identifier to a
an interface

>  How important is "partial specification" and "partial
> understanding" in all this?

I don't believe it matters at all to the binding issue.  It just helps
with integration.

 [1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0099

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Tuesday, 7 January 2003 00:09:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC