revisiting the context structure

Since there's been no feedback on the CAF model diagram and text I sent, Greg and I thought that we'd try to move things along in the editors list and then present the results to the group. With that in mind, I'd like to start by revisiting the context structure (I'll send each issue in a separate email). In case you don't have the last email to hand that contained the issues (I removed them from the text that was sent to the group to increase clarity), it said:

[answer: multiple   ALSs can register their involvement in specific
activities, and by doing so form   a single protocol. How this is
accomplished, and precisely how a user of a context/activity service
knows what the semantics   are of a   specific protocol, is not
defined. Likewise, it is outside scope for a context service to know
when all required ALSs have been registered for a protocol.

In terms of augmentation, the intended scenario was that each ALS is
given its current context (the last addition to the global context it
provided, or null if this is a new top-level activity) to update, and
this new context is added to the global context.

<xs:complexType name="ContextType">
<xs:sequence>
  <xs:element name="context-identifier" type="xs:anyURI"/>
  <xs:element name="activity-service" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="type" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="activity-list" minOccurs="0">
   <xs:complexType>
    <xs:sequence>
     <xs:element name="service" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    <xs:attribute name="mustUnderstand" type="xs:boolean" use="optional" default="false"/>
    <xs:attribute name="mustPropagate" type="xs:boolean" use="optional" default="false"/>
   </xs:complexType>
  </xs:element>
  <xs:element name="child-contexts" minOccurs="0">
  <xs:complexType>
   <xs:sequence>
    <xs:element name="child-context" type="tns:ContextType" maxOccurs="unbounded"/>
   </xs:sequence>
   </xs:complexType>
  </xs:element>
  <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="timeout" type="xs:int" use="optional"/>
</xs:complexType>

the   idea was that   the ##other   would be the ALSs extension
element.   However, this and other   things about the current context
structure   are    broken (possibly   cut-and-paste errors in   some
cases). For example, the mustUnderstand attribute is meant to apply to
a specific ALSs data, and not to the activity-list.

<xs:complexType name="ContextType">
<xs:sequence>
  <xs:element name="context-identifier" type="xs:anyURI"/>
  <xs:element name="activity-service" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="type" type="xs:anyURI" minOccurs="0"/>
  <xs:attribute name="timeout" type="xs:int" use="optional"/>
  <xs:element name="activity-list" minOccurs="0">
   <xs:complexType>
    <xs:sequence>
     <xs:element name="service" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
   </xs:complexType>
  </xs:element>
  <xs:element name="als-data" minOccurs="0">
   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   <xs:attribute name="mustUnderstand" type="xs:boolean" use="optional" default="false"/>
   <xs:attribute name="mustPropagate" type="xs:boolean" use="optional" default="false"/>
  </xs:element>
  <xs:element name="child-contexts" minOccurs="0">
   <xs:complexType>
    <xs:sequence>
     <xs:element name="child-context" type="tns:ContextType" maxOccurs="unbounded"/>
    </xs:sequence>
   </xs:complexType>
  </xs:element>
</xs:sequence>
</xs:complexType>

However, this ignores the reason that the activity-list was added: to
enable services (not ALSs) to be added to the context as the context
"visits" each service. Assuming we still want to support that, then the context would look more like:

<xs:complexType name="ContextType">
<xs:sequence>
  <xs:element name="context-identifier" type="xs:anyURI"/>
  <xs:element name="activity-service" type="xs:anyURI" minOccurs="0"/>
  <xs:element name="type" type="xs:anyURI" minOccurs="0"/>
  <xs:attribute name="timeout" type="xs:int" use="optional"/>
  <xs:element name="als-data" minOccurs="0">
   <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   <xs:attribute name="mustUnderstand" type="xs:boolean" use="optional" default="false"/>
   <xs:attribute name="mustPropagate" type="xs:boolean" use="optional" default="false"/>
  </xs:element>
  <xs:element name="activity-list" minOccurs="0">
   <xs:complexType>
    <xs:sequence>
     <xs:element name="service" type="xs:anyURI" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
   </xs:complexType>
  </xs:element>
</xs:sequence>
</xs:complexType>

If we consider changing the context structure to have one element per
ALS, rather than one element with entries for each ALS within it, then
the activity-list data structure probably becomes a separate context
element generated by the context service.]

After thinking about this further, I'm concerned that the current structure may inhibit adoption by potential users of the specification because it does require a change to existing context structures. If we take the case of an activity that has security and transactions involved, then the current format of that context would be:

It seems to me that from the start we've said that existing services should just be able to plug in to Context and be used as-is. However, that's not the case, because we would mangle their current context structures into our own. Is this is a big thing? What it does is allow non-Context aware services to be driven within a Context activity transparently - they just can't tell the difference since the context structure is identical.

One solution would be to have a single element per service in the SOAP header block, exactly as the above example shows. But what are the advantages of Context then? Well, there's the pluggability aspect of it, that would remain (relatively) unchanged. Each ALS is still asked to augment the context, and the Context Service still maintains a well defined context structure per activity. All we're changing is the format of that structure.

A side-effect of such a change is that we'd lose the automatic nesting structure of the context. However, how services (ALSs) deal with nesting in their own context element is up to them. The problem comes if there's a required relationship between the various contexts (e.g., transactions only belong to the lowest-level child in a nested activity.) I haven't had a chance to fully think the implications of this change through yet, but I suspect we could either punt on this to the respective specifications, or provide some related-to schema element:

ws-caf-editors message