[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] context block or one element per type
Interesting.
I had
assumed the usual way of dealing with representing contexts and the
protocol-specific information would be as Greg describes - each context is a
soap header containing the stuff for its (combination of) protocol and there can
be multiple headers of base type wsctx:ctx. :
Mark's
proposal startled me, partly because it raises a question about context as a
whole, at least context-by-value (this is partly a reprise of some of the
Paris discussion)
If it
is possible for a compound context to be broken up, with its protocol-specific
elements travelling in their own right, and a context element to define the
relationship, then presumably one could do the same with simple (one protocol)
context. In which case, what semantic is being carried by the context in that
case? Is it needed as a header at all ? And then the same argument applies to a
simple context in the normal arrangement - if the protocol-specific
content is intelligible on its own, what has been gained by putting it inside a
context, in addition to making it a header ? This was one of my points in Paris
- context-by-value is not needed
Of
course, there is a semantic in the multi-protocol case : the context wrapper (or
references in the context) mean "these two are to be considered together, in
accordance with the rules defined in uri ....", the uri being that of the
context-type ( aka ALS-configuration-identifier, I think)
But
that raises another question with these multi-protocol contexts: who is supposed
to implement the combination rules ? The Context Service is, as I understand it,
unaware of what the different context types mean - it just goes round all
its enlisted ALS's asking if they would like to make a contribution. If it
is unaware of different types (i.e. one could take a Context Service
implmentation and use it with ALSes and a context-type that were unknown when
the Context Service was written), then it can only have a very simple
combination rule - put the stuff from each ALS in the context in an arbitrary
order.
If
anything more sophisticated is needed (order the requests to the ALSes,
structure the combining of their responses) then the Context Service has to
implement the combination, and the Context : ALS relationship is no longer the
use-agnostic interface it appeared. And is it really going to be common that
independent ALSes can just be combined without modifying the ALSes themselves ?
It seems much more likely that the Context+ALSes group will be the
implementation unit - in which case, separating them out in an interoperable way
isn't really worth it.
Which
in turn means there is no such thing as a general multi-protocol <context>
element. There are contexts (in the sense of soap headers on application
messages that contain information relevant to supporting protocols/mechanisms)
but their internal content is specific to the combination, in the same way as
the content of a single-protocol context is specific to the protocol. And
it we are back to considering why:
<wsctx:context>
<wsctx:type>uri_for_foo_and_bar_combination</wsctx:type>
<foo:contextinfo
xmlns:foo="foo_schema_uri"> ... <foo:data>
<foo:contextinfo xmlns:foo="foo_schema_uri"> ...
<foo:data>
<bar:data
xmlns:bar="bar_schema_uri"> ... <bar:data>
</wsctx:context>
is easier to cope with as a header
than
<foobar:context
xmlns:foobar="uri_for_foo_and_bar_combination">
<bar:data
xmlns:bar="bar_schema_uri"> ... <bar:data>
</foobar:context> As I
mentioned, some of this was raised in Paris, but I don't remember a clear
answer, and it would be good have it on the archive if I've forgotten it/failed
to understand it.
Peter
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]