Base factory interface

["Green, Alastair J." <Alastair.Green@choreology.com>]

I have already stated my view of the "value proposition" of WS-Context
(as opposed to a message part, conventionally thought of as mapping to a
SOAP header element).

1. Base class for relationship attributes
2. Generic factory interface
3. Possible value of by reference

We are perilously close to knocking away "base class for statement of
relationship attributes". (See earlier mails on mustPropagate and
mustUndertand.)

Let's turn our attention to the generic factory interface.

The interface is very simple (in notional CORBA IDL for economy and
legibility):

	context begin()
	context begin(in context)

begin must either state type, in which case a child element reflecting
the type statement must be enclosed in the outbound context, or (if it
fails to state type), the context will have no child element. In this
latter case we have got WS-GetUUID.

Parenthetically: let's add that back in as value prop element 4:
get_uuid by SOAP. Not convinced it would justify a whole spec on its
own, but it is a feature of potential value.
 
Let's go back to the variant where the type is stated.

Surely, in almost all conceivable circumstances, the version of begin
where a parent context is passed, is going to require that the in
context and the out context are of the same type?

If this is true, then we want a type-safe way of expressing that form of
begin. This is very difficult to achieve: we now have to create
overloads of the begin-with-context operation, which use types which
extend the base context. As I understand it, this is not a popular
approach in the real world. 

In which case, why don't we just define this painfully simple interface
anew, in a type-specific way, in each referencing specification, e.g.
WS-CF.

It might be useful to document it as a "template", I suppose. But that
is not a good case for a full-blown interop spec.

Alastair