Prefixes and Properties Defined in SOAP 1.2 and Proposed Additions

The following tables provide the prefix mappings used throughout these documents, as well as a quick reference to the properties defined in the core specifications and submitted as part of these proposals.

Table 1. Prefix Mappings Defined in SOAP 1.2
Prefix Namespace
xs http://www.w3.org/2001/XMLSchema
xsi http://www.w3.org/2001/XMLSchema-instance
env http://www.w3.org/2002/06/soap-envelope
enc http://www.w3.org/2002/06/soap-encoding
contexthttp>//www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/
reqres http://www.w3.org/2002/06/soap/mep/request-response/
fail http://www.w3.org/2002/06/soap/mep/FailureReasons/

In the following table, note that all namespaces given are under the administrative control of the vendor sponsoring this submission. It is expected that if these features are adopted, these namespace URIs will be replaced by URIs under the administration of the appropriate W3C working group.

Table 2. Proposed Prefix Mappings
Prefix Namespace
solicit http://www.tibco.com/xmlns/soap/mep/solicit-response/
notify http://www.tibco.com/xmlns/soap/mep/notification/
confirm http://www.tibco.com/xmlns/soap/mep/confirmation/
auth http://www.tibco.com/xmlns/soap/mep/authentication/
arr http://www.tibco.com/xmlns/soap/mep/asynchronous-request-response
address http://www.tibco.com/xmlns/soap/message-address/
corr http://www.tibco.com/xmlns/soap/message-correlation/
faildesthttp://www.tibco.com/xmlns/soap/failure-destination/
mimeconthttp://www.tibco.com/xmlns/soap/mime-content/
mimecomphttp://www.tibco.com/xmlns/soap/mime-composite/

 

Table 3. Properties Defined in SOAP 1.2
Name Type ConstraintsNotes
context:ExchangePatternName anyURI
context:FailureReason enumeration of string 5
context:State enumeration of string 1, 2, 5
context:CurrentMessage message 1, 3, 6
context:TriggerMessage message 1, 3, 6
context:ImmediateSource anyURI 1
context:ImmediateDestinationanyURI 1
reqres:Role enumeration of stringRequestingSOAPNode|RespondingSOAPNode4, 5

Notes

  1. A number of properties defined in the reqres pattern have been promoted here, because there seems to be no good reason to repeat these definitions for every MEP. These properties are common across MEPs.
  2. The set of possible states has been modified for greater utility across MEPs.
  3. The concept of the current message appeared in earlier drafts, and seems far more universally useful than forcing it into the reqres inbound/outbound pair. TriggerMessage, here, then becomes the message that caused a response (or fault), the previous CurrentMessage.
  4. Tying Role to an exchange pattern is problematic; loosing it therefrom is as well. Possibly a better solution would be context:Role, specified as a list of the roles that the node is willing to play (which may be reduced to a single role during an exchange).
  5. These items are described as URIs when introduced, but do not take any known URI form when values are presented. They are treated here as enumerations over xs:string.
  6. The type of a message is complex; it is "an abstract structure that represents [... a message in the ...] exchange [, ...] both SOAP envelope and any other information structures that are transferred along with the envelope."
Table 4. Proposed Property Definitions
Name Type Constraints
arr:Role enum RequestingSOAPNode|RespondingSOAPNode
conf:Role enum RequestingSOAPNode|ChallengingSOAPNode
solicit:Role enum SolicitingSOAPNode|RespondingSOAPNode
solicit:TermCondition enum First|Number|Time|Notification
solicit:Synchronous boolean
solicit:NumRespondents int
solicit:Deadline date
notify:Role enum NotifyingSOAPNode|NotifiedSOAPNode
auth:Role enum RequestingSOAPNode|ControllingSOAPNode
address:original-source anyURI
address:final-destination anyURI
address:response-address anyURI
corr:message-id string unique within a conversation
corr:references array of string
faildest:failure-destinationanyURI
mimecont:version string
mimecont:content-type string
mimecont:transfer-encodingstring
mimecont:* various
mimecomp:content-type string
mimecomp:content-id string
mimecomp:content-location anyURI
mimecomp:current-part message part

We need to get the constraints into this table, too, 'kay?

Notes

The repetition in the MEPs is fairly bothersome. It might be worthwhile to factor out OriginalSource, FinalDestination, and ResponseAddress into a feature, into which ImmediateSource and ImmediateDestination might be joined (from Context), call the whole thing "addressing", and make it a required feature for all MEPs (it would be implicit in synchronous MEPs, of course). The clarity of the features stands in marked contrast, even though many of the MEPs mentioned here require one or more of the features.

Role is really problematic. It's clear that the role is defined by a MEP, but it isn't clear that the way that it's currently defined is adequate (intermediaries are currently defined as playing roles in succession; would it be more accurate to say that they are playing the role of intermediary?). And even though each MEP defines roles, the concept of role itself is larger than an individual MEP. *sigh*


Amelia A Lewis
Last modified: Wed Oct 9 11:33:14 EDT 2002