W3C home > Mailing lists > Public > www-archive@w3.org > November 2001

RE: TBTF text for f2f

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 22 Nov 2001 10:33:31 -0000
Message-ID: <5E13A1874524D411A876006008CD059F19278B@0-mail-1.hpl.hp.com>
To: "'Mountain, Highland M'" <highland.m.mountain@intel.com>
Cc: "Noah Mendelsohn (E-mail)" <Noah_Mendelsohn@lotus.com>, "David Fallside (E-mail)" <fallside@us.ibm.com>, "Christopher Ferris (E-mail)" <chris.ferris@sun.com>, "Glen Daniels (E-mail)" <gdaniels@macromedia.com>, "Hugo Haas (E-mail)" <hugo@w3.org>, "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, "Yves Lafon (E-mail)" <ylafon@w3.org>, "Oisin Ohurley (E-mail)" <ohurley@iona.com>, "Marc. Hadley (E-mail)" <marc.hadley@sun.com>, "Mark A. Jones (E-mail) (E-mail)" <jones@research.att.com>, "'www-archive@w3.org'" <www-archive@w3.org>
Hi Highland,

> As a side note, in reference to Stu's thoughts and one of my original
> comments, it appears that bindings and binding specifications are 2
separate
> documents.

When we talked on the phone what I said was that I think of a binding
specification as a document (a human readable document). I think of a
binding as an instantation (or a realisation - practically a (deployed)
implementation) of that behaviour.

I think that there are (at least) four concepts that may be getting tangled
up.

a) A binding specification: Which declares what features bindings conforming
to that specification supports and how to make use of the services of the
underlying protocol to provide those features.

b) The abstract behaviour that the binding specification describes - a
description of behaviour can change without the described behaviour
changing. There should only be one of these per binding specification.
[However, there could be many specifications that describe the same
behaviour.]

c) The design... and ultimately source and object code that implements the
behaviour specified in binding specification. This will be targetted on a
particular operating environment which may be homogenous or modular. In
general I think we stay well clear of this stuff. There may be many of these
per binding specification.

d) A deployed, configured (if appropriate) and operational instance of such
an implementation - one hopes that there will be may of these per
design/implementation.

I think the term 'binding specification' is clear.

I think the use of the undecorated term 'binding' is less clear. I think it
could reasonably be applied to b) (eg. the behaviour specified in the
normative W3C SOAP/SMTP binding specification), c) (eg. the Apache Axis
implementation of the behaviour specified in the normative W3C SOAP/SMTP
binding specification) or d) (eg. a particular deployment of the Apache Axis
SOAP/SMTP binding implementation on xmlp.w3.org).

Mostly I think I use the term binding for a d) which I also think of as a
'binding instance'.

> Examples should be provided to illustrate a binding and a
> binding specification, to clearly call out the differences in the two
> documents and their usage.

Binding spec... I think we can provide an example of one (or more) of those.

Binding as abstract behaviour, (b) above... that's hard... it's abstract...

Binding as design/implementation, (c) above... while reasonably one could
think of these as documents (or at least files) I think it would get us into
a bunch of trouble to provide an example of an implementation/design.

Binding as an instance of deployment, (c)... I think that we can talk about
that in the same sense that we can talk about SOAP Nodes and SOAP
Processors.

> Providing just an HTTP Binding Specification,
> would be incomplete, and would not fully illustrate what our framework
> provides(IMHO).  By saying this, I am not advocating this approach(yet),
but
> asking for more clarity if we do go this route.  (Glen - Are you planning
on
> covering such examples in your ftf presentation?)

I hope I've added clarity rather than confusion... but I fear the latter.
again, FWIW these are just my thoughts.

Best regards,

Stuart
Received on Thursday, 22 November 2001 05:41:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:14 GMT