RE: TBTF text for f2f

Stu,

Thanks for the detailed note.  After the flurry of email last week, it
became apparent that there may have been some miscommunications.  Here is my
source of apprehension regarding the current doc...as I read the statement,

 "It is up to the communicating nodes to decide how best to express
particular features; often when a binding-level implementation for a
particular feature is available, utilizing it when appropriate will provide
for optimized processing.",

it seems like something is missing, in terms of examples or guidance to our
audience.  What is being fed into the communicating nodes to allow them to
"decide how best to express particular features"(if it is something like
WSxL, should we not just say so)?  Are we implying that these "decisions"
are being made via an automated process?

Most of you will be meeting ftf in Boston and will be discussing this issue.
I would appreciate it if a con-call could be available for any TBTF ftf ( I
will set up the call, just let me know the date/time).  

Thanks,

Highland

-----Original Message-----
From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
Sent: Thursday, November 22, 2001 3:34 AM
To: 'Mountain, Highland M'
Cc: Noah Mendelsohn (E-mail); David Fallside (E-mail); Christopher
Ferris (E-mail); Glen Daniels (E-mail); Hugo Haas (E-mail); 'Henrik
Frystyk Nielsen'; Yves Lafon (E-mail); Oisin Ohurley (E-mail); Marc.
Hadley (E-mail); Mark A. Jones (E-mail) (E-mail); 'www-archive@w3.org'
Subject: RE: TBTF text for f2f


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 Monday, 26 November 2001 11:34:40 UTC