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.
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 |
context | http>//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.
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/ |
faildest | http://www.tibco.com/xmlns/soap/failure-destination/ |
mimecont | http://www.tibco.com/xmlns/soap/mime-content/ |
mimecomp | http://www.tibco.com/xmlns/soap/mime-composite/ |
Name | Type | Constraints | Notes |
---|---|---|---|
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:ImmediateDestination | anyURI | 1 | |
reqres:Role | enumeration of string | RequestingSOAPNode|RespondingSOAPNode | 4, 5 |
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-destination | anyURI | |
mimecont:version | string | |
mimecont:content-type | string | |
mimecont:transfer-encoding | string | |
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?
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*