RE: [ws-caf] proposal towards a resolution for issue 132

["Murray, Bryan P." <bryan.murray@hp.com>]

Thank you for your answers Peter - they are pretty much what I thought
they were. I think information like this should be added to the spec. I
was asking the questions partly tongue-in-cheek to point out that if you
want interoperable implementations you need to be very explicit in the
specification. Most implementers will not have the benefit of the
collective knowledge in the heads of the TC members that has been worked
out in a lot of discussions over the development of the spec. I am sure
there are other places in the spec that should similarly be clarified.


Regarding type

Since it is likely that other specifications will want to build on the
generic context provided by WS-Context, perhaps a section should be
added to the spec indicating how other specs should be built on this
one. For instance a referencing spec needs to indicate what the context
type must be set to, any additional fields in the context structure, and
the behavior of a given role operating with the specified type of
context. Another topic that could go in this section is how a
referencing spec should extend the basic context: does the SOAP header
have to use the element name "context" or does it just need to have a
type that extends the context complex type and any element name may be
used?

The "begin" message should mention the required type field (and I agree
with you Peter - it should be named consistent with the text,
protocol-uri is not mentioned in the text at all).

The spec should probably say that a message must not contain more than 1
context header having the same value for type (and if it is optional,
not more than one message that omits the type).

Bryan


-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] 
Sent: Friday, June 25, 2004 4:05 PM
To: Murray, Bryan P.; Green, Alastair J.; Newcomer, Eric; Greg Pavlik
Cc: Mark Little; ws-caf
Subject: RE: [ws-caf] proposal towards a resolution for issue 132


On looking at the text, I believe Bryan is right, and that the type
field is under-specified at the moment. I'd never noticed, partly
because I was looking for a field with the semantic outlined below, and
inflated the text that is actually there with what I thought it meant.
On this occasion, I think, from exchanges over the months, my
understanding was close to that intended by the authors - but it doesn't
actually say so, and Bryan's questions are are not resolved in the text.
This can be taken as an object lesson in what an open specification must
say - you dare not assume others will understand what you meant if you
don't say it explicitly (which is why "thunk factor" comparisons are
specious)

So, my understanding of the type (defined as "indicating the type of the
protocol") is that identifies a particular context-using protocol. A
type URI is assigned by a referencing specification to identify itself
and the procedures, data elements and services it specifies. It could be
identical to the namespace of the xml of that referencing spec, or could
be different. (I see no distinction between a "referencing
specification" and a "context [-using] protocol", other than that one
defines the other - in fact, in this case "context[-using] protocol" is 
better, as it avoids ambiguity for the case where one document specifies
more than one protocol (set of rules) and thus more than one type URI.

As an identifying URI, the constraints on the URI are only that the
assignor can be sure no-one else will assign it, and that it won't be
re-used for something else of the same kind. Thus you can make it the
URL of your favourite web site,  but used as a context type, provided
you can be sure no-one else will. (you can bend the re-use rule if the
extent of its use is tightly known). The URI can be from any uri scheme
(http:, urn:, etc). It is just an unambiguous name.

As URIs they are the same if they match lexically (I think there is an
ietf (?, w3c ?) spec defining exact rules for this, to canonicalise
escapes, though normally case sensitive string match will work)

On this interpretation, yes you could use type as a despatching
mechanism. 

The context receiver needs to know the type because without it, there is
no well-defined behaviour the receiver can be expected or required to
follow, other than any behaviour specified in the base context, or
implied by 
the application the context is being sent with.  The behaviour specified
in the 
base context is under consideration in other issues, and could well turn
out to be none. Implying the context protocol from the application 
protocol is what Alastair is suggesting.

I believe the type is initially set in the begin message (though the xml
for begin seems to call it a protocol-uri - the names shoulod be
aligned). It is thus chosen by the initiating requestor from the set of
context protocol names known.

Peter