ws-caf message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Resend: [ws-caf] specifications - referencing and otherwise
- From: "Furniss, Peter" <Peter.Furniss@choreology.com>
- To: <ws-caf@lists.oasis-open.org>
- Date: Tue, 6 Jul 2004 18:27:55 +0100
Title: Message
The
oasis email archiver mangles messages that have "From " as the first characters
on a line, so I am resending this for the record.
In yesterday's
discussion, it seemed that there may be different views about what is meant by
"referencing specification", and since, I think, I first put the term into
ws-caf circles (issue 64), and I use the term very frequently in discussions on
this list, I thought I'd expand on what I understand by it. I believe
the term is used in 0.3 in the same sense, though I haven't checked
explicitly.
One can
distinguish various sources of definition for the behaviour of a particular
web service and its client using ws-context:
a) general
web-service specification - soap, xml, mime-types etc
b) the particular
application protocol - whose data is carried in the soap
body
c) the ws-context
specification itself
d) other
specification building on ws-context that defines the meaning and implication of
the context header
e) specification of
other soap headers
f) implementation
choices
One could chop
things differently, and certainly name things differently, but the key
characteristics are:
a-e all have to be
understood by both parties; f) is defined as being of concern only to one side.
If a-e offer a choice to one implementation on what is sent, then a-e must also
demand that the other side can accept and handle anything arising fr-om that choice. (if
a-e do not do this, they are broken as interoperable
specifications)
The use of the term
"specification" is not intended to imply any special level of formalisation -
other than the critical feature that both sides must understand and implement
the same (or corresponding) thing.
a) is the substrate
on which we are working, so can be left out of further discussion (though
obviously affects reality)
the distinction
between b) and (c+d+e) is inherent in the soap body + headers pattern. In one
sense, the totality of the message is part of the application protocol. However,
the concept of a header implies a piece of specified protocol (messages and
behaviour) that has been factored out of the application (usually on the basis
that it is common to many application protocols).
c+d together define
the semantics of a particular SOAP header that uses ws-context. The
specification d) may or may not add extension elements to the base ws-context
<context> element. It may or may not imply the existence of other web
services (like a coordinator). d) may itself be compound or layered (as with the
input versions of ws-cf + ws-txm lra, say).
F-r-o-m the perspective of the ws-context document,
"referencing specification" was meant to refer to d) - i.e. that which must be
mutually understood by both parties concerning the ws-context header as a whole
but which is distinct from the particular application protocol. The same thing
is also sometimes called a "higher specification"
It is also this "d)"
that is identified by the context type URI, in my
understanding.
Since, in a sense,
the whole SOAP envelope is an application protocol message (e.g. an update
request with a ws-txm acid context is not seeking the same behaviour as an
update request with no transactionish context), it can be argued that the d) :
b) boundary is ill-defined. A WSDL definition is the normal way of stating the
application protocol's interface, but if the WSDL binding demands that
particular headers carry particular values, then the header:body distinction
becomes perhaps insignificant. However, insofar as it made sense to factor out
the header in the first place, a distinction can usefully be
made. Using a header, rather than carrying the field in the application's
"own" protocol presumably picks up some semantics that consequently don't need
to be spelled out in the application protocol's specification (which may be no
more than some human-language text explaining the methods and parameters, or
they may even be assumed to be "obvious" f-rom their names - though that would be rather
under-specified)
The "referencing
specification" is thus a placeholder term for everything that has to be
known to both sides, isn't in the ws-context document and is
intended/implied by the use of the context header in a particular
case.
I think it would be
appropriate to have an explanation of a "specification model" of this nature in
the text. This would be essentially editorial (it explains the text, without
changing the requirements on implemenations) but we need to be sure of
consensus
So, if the above is
contrary to your perception, please correct or refute.
Peter
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]