RE: Capturing Noah's Goal - Framework Description for Nov 5

Glen,

Thanks for your feedback.  Please clarify, are you implying that a Transport
Binding will only specify features and properties satisfied by the
underlying protocol? This would imply the need for application-level
requirement specs covering a message exchange, if that message exchange is
not satisfied by an underlying protocol?  

If so, would you agree that if the underlying protocol did satisfy the MEP,
there would be no need for such an application-level requirement
spec(because the transport binding would cover it)? 

This would imply that the "application-level requirement bar" and the
"binding-level requirement bar" are dynamic and determined by the native
feature set of the transport protocol.  Correct?  If so, then the merging of
your last sentence with my suggested text does not fit:


> Any binding specification has a set of messaging requirements.  Some of
these requirements could be satisfied by the underlying protocol's native
feature set.  Other requirements may need to be provided outside of the
underlying protocol. The requirements not provided natively by the
underlying protocol of choice will need to be expressed in the resulting
binding specification <here is where the problem is, where do such
requirements belong>.  These requirements will be expressed as features and
associated properties.  SOAP nodes will have to determine which resident
modules satisfy the features outside the scope of the selected binding in
order to be compliant with the application-level requirements for the
message exchange.

Thoughts?

Highland

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@macromedia.com]
Sent: Friday, November 02, 2001 4:23 PM
To: Mountain, Highland M; David Fallside (E-mail)
Cc: 'Oisin Hurley'; 'Hugo Haas'; Chris.Ferris@sun.com;
marc.hadley@sun.com; 'Mark Nottingham'; 'Noah Mendelsohn';
ylafon@w3.org; 'Mark A. Jones (E-mail)'; www-archive@w3.org; Stuart'
'Williams (E-mail); Henrik Nielsen (E-mail)
Subject: Re: Capturing Noah's Goal - Framework Description for Nov 5



Hm.

The last sentence, as written, I don't think I agree with.  It seems to
imply that modules can be used to satisfy binding-level requirements, which
I don't believe is really the right way to look at it.  Let me try first to
make a general statement about the framework, and then to rephrase some of
what the original paragraph says in a way that I hope may help.

The binding framework does two things for us - first, it allows binding
authors to specify the features their binding provides in a way that allows
the authors of other specifications (bindings or modules) to provide those
same features.   Second, by virtue of the fact that both bindings and
modules can use the same specification language to talk about Features, we
enable the software at a SOAP node to be written such that it can make
decisions about which modules (and perhaps bindings) to engage for a
particular message exchange based on an abstract set of desired
Features/Properties.

An underlying protocol will have a certain set of semantics and behaviours.
The author of a binding utilizing a particular protocol will have the option
to a) completely ignore any underlying protocol semantics (i.e. the binding
is "opaque"; the underlying protocol still has all its behaviour, but the
SOAP node doesn't know about any of it), b) express some or all of the
semantics provided by the underlying protocol as Features/Propertes, thus
enabling the larger SOAP environment to see and make decisions based on
these, or c) specify semantics which go BEYOND those of the underlying
protocol, and perhaps expose some of those semantics as Features/Properties.
An example of the latter would be a binding that implements request-response
over UDP in a particular fashion, or a binding that uses the MIME
specification to describe its data packaging over a bytestream underlying
protocol.

In other words, a binding is a black box to the SOAP node.  The only
connection points we have to the black box are the Features and Properties
which are exposed in the binding specification, and we have no way of
knowing which of those Features are directly supported/supplied by the
underlying protocol, and which are part of the binding specification.  This
is as it should be.

The end result of all this is that the only connection between the modules
and the bindings is that they both expose particular Features/Properties in
their specifications.  So the last sentence below is almost right, except
that I would say it's "SOAP nodes will have to determine which resident
modules satisfy the features outside the scope of the selected binding in
order to be compliant with the application-level requirements for the
message exchange".

Hope this made some sense.

--Glen

> Any binding specification has a set of messaging requirements.  Some of
> these requirements could be satisfied by the underlying protocol's native
> feature set.  Other requirements may need to be provided outside of the
> underlying protocol. The requirements not provided natively by the
> underlying protocol of choice will need to be expressed in the resulting
> binding specification.  These requirements will be expressed as features
and
> associated properties.  SOAP nodes will have to determine which resident
> modules satisfy the features outside the scope of the underlying protocol,
> in order to be compliant with a given binding specification.
>
> The last statement is where we need to arrive at a common understanding.
>
>
> Talk to you Monday.
>
> Highland
>
>

Received on Friday, 2 November 2001 19:07:54 UTC