- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Thu, 22 Nov 2001 10:33:31 -0000
- 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 UTC