OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: i115: updated proposal


Below is an updated proposal for i115. The only change has been highlighted. The purpose of the change is to make it clear that you can only add wsrm:mU to the top-level extension elements.
 
- gp
 

1.1 Glossary

The following glossary defines a set of terms used to describe some of the different messages related to WS-RM:

Sequence Lifecycle Message: A message that contains one of: <wsrm:CreateSequence>, <wsrm:CreateSequenceResponse>, <wsrm:CloseSequence>, <wsrm:CloseSequenceResponse>, <wsrm:TerminateSequence>, <wsrm:TerminateSequenceResponse> as the child element of the <soap:Body> element.

RM Protocol Header Block: One of <wsrm:Sequence>, <wsrm:SequenceAcknowledgement>, or <wsrm:AckRequested> elements.

RM Component: One of the elements that either make up the body of a Sequence Lifecycle Message or that appears as an RM Protocol Header Block.

Sequence Traffic Messsage: A message that contains a <wsrm:Sequence> header block.

Acknowledgement Message: A message that contains a <wsrm:SequenceAcknowledgement> header block.

3.7 Extension Elements

The definition of each of the RM Components includes an extension point that allows the addition of elements to that RM Component. It is likely that specifications for a wide variety of extensions to these RM Components (termed “RM extensions” for the purposes of this discussion) will be developed over time and that some RM nodes might include the software necessary to implement one or more such extensions. An RM extension is said to be understood by an RM node if the software at that RM node has been written to fully conform to and implement the semantics specified for the XML expanded name of the outer-most element information item of the extended element.

An RM extension element MAY carry a wsrm:ustUnderstand attribute information item. When the value of such an attribute information item is "true", the RM extension is said to be mandatory. The wsrm:ustUnderstand attribute information item SHALL NOT be carried by any element that is not the outer-most element information item of the element extending an RM Component.

Mandatory RM extension elements are presumed to somehow modify the semantics of other RM Components. Therefore, for every mandatory RM extension recieved by an RM node, the receiving node MUST either process the element or not process the element at all, and instead generate a wsrm:MustUnderstandFault. Tagging RM extensions as mandatory thus assures that such modifications will not be silently (and, presumably, erroneously) ignored by the RM nodes that recieve the messages containing extended RM Components.

4.9 MustUnderstandFault

This fault is generated when an RM node (RMS or RMD) is presented with a Sequence Lifecycle Message or RM Protocol Header Block that contains an extension that is tagged with a wsrm:mustUnderstand attribute with a value of "true" and that node does not understand that extension element.

Properties:

[Code] Client or Server (as appropriate)

[Subcode] wsrm:MustUnderstandFault

[Reason] Do not understand the extension marked as "must understand"

[Detail]    xs:any



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]