- reusing existing ebMS schema elements (i.e. no new
eb:Select): yes
- adding more "query" options like From/PartyId : well if
we do so then why not Service/Action too...
The initial idea with reftomessageId and
conversationId was to focus on items that typically correlate MEPs or
conversations, as you may want to control / complete the pulling of such message
sequences.
Of course from an implementation viewpoint it does not take
much effort to support additional selection features, once you support these.
Still, these are additional features, more interoperability risks... (how will
combinations work?)
So I am not opposed to specifying a broader set of
selection features with additional header elements, but then I'd only require
support for eb3:RefToMessageId and eb3:conversationId in the baseline conformance profile to
be defined in the Conformance Clause ...(these two features to be used
separately, never in combination)
Jacques
Hello Jacques,
Yes, I believe this backwards compatible. I think we
could just reuse the elements in the ebMS schema instead of inviting a new
eb:Select element:
And
similarly for ConversationId.
What
do we win/loose by adding other standard header elements like From/PartyId
?
Pim
Based on
todays's discussion:
Here are some samples of extended PullRequest, followed
by the proposed (rough) schema.
I believe this
is still backward compatible, Pim? (PullRequest allows for a sequence of any as
children elements)
Semantics:
The MSH
receiving such a PullReques MUST either:
(a) return a
message assigned to the same @mpc, and that has same eb:RefToMessageId value as
@reftomessageid (if the latter is specified) and same eb:ConversationId value as
@conversationid (if the latter is specified) and that contains the message
properties specified as children of <eb:Select> (if
any).
(b) return
error EBMS:0006 (EmptyMessagePartitionChannel ) if no message is currently
assigned to this MPC , that matches the selecting conditions in
(a).
Examples:
<eb:SignalMessage>
<eb:MessageInfo>
<eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
<eb:MessageId>UUID-2@initiator.example.com</eb:MessageId>
</eb:MessageInfo>
<eb:PullRequest mpc="http://msh.example.com/mpc123">
<eb:Select reftomessageid="1234"/>
</eb:PullRequest>
</eb:SignalMessage>
<!--
============================= -->
<eb:SignalMessage>
<eb:MessageInfo>
<eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
<eb:MessageId>UUID-2@initiator.example.com</eb:MessageId>
</eb:MessageInfo>
<eb:PullRequest mpc="http://msh.example.com/mpc123">
<eb:Select conversationid="6"/>
</eb:PullRequest>
</eb:SignalMessage>
<!--
============================= -->
<eb:SignalMessage>
<eb:MessageInfo>
<eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
<eb:MessageId>UUID-2@initiator.example.com</eb:MessageId>
</eb:MessageInfo>
<eb:PullRequest mpc="http://msh.example.com/mpc123">
<eb:Select>
<eb:Property
name="POclass">urgent</eb:Property>
<eb:Property
name="ProductType">expensive</eb:Property>
</eb:Select>
</eb:PullRequest>
</eb:SignalMessage>
<!--
============================= -->
<eb:SignalMessage>
<eb:MessageInfo>
<eb:Timestamp>2006-07-25T12:19:05</eb:Timestamp>
<eb:MessageId>UUID-2@initiator.example.com</eb:MessageId>
</eb:MessageInfo>
<eb:PullRequest mpc="http://msh.example.com/mpc123">
<eb:Select>
<eb:Property
name="POref">PO2345</eb:Property>
</eb:Select>
</eb:PullRequest>
</eb:SignalMessage>
------------------------------- schema:
-----------------------------------------
<xsd:complexType
name="PullRequest">
<xsd:sequence>
<xsd:element
name="Select"
minOccurs="0">
<xsd:complexType>
<xsd:sequence
minOccurs="0">
<xsd:element
name="Property" type="Property"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute
name="reftomessageid"
type="non-empty-string"/>
<xsd:attribute
name="conversationid"
type="non-empty-string"/>
</xsd:complexType>
</xsd:element>
<xsd:any
namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup
ref="pullAttributes"/>
</xsd:complexType>