I'm in the midst of getting my many editorial comments together and don't
think I've got time to put words into enough of this. I can make a few
relatively specific recommendations:
* Don't add the note I mentioned earlier and Shimamura-san inserted below.
* Use NotSupported to mean the MSH refuses to support a particular requested
feature (for example because it's not in the agreed-upon CPA). That should
affect all CPA / instance differences such as line 819, 1408, 1630-1631,
1790-1791, 1899-1900, 2025 and 2049.
* Update the description of NotSupported to specifically include this
meaning ("at odds with the CPA").
** As an alternative to the two points above, could define a new error
meaning just "at odds with the CPA" but because a CPA shouldn't include
anything you don't support the difference should be moot.
* Leave Inconsistent alone -- meaning the instance is internally
inconsistent.
* Soften section 1.3.6 as I describe below (sorry, just in general terms).
* I've got some editorial comments on section 4.2.2.1.2. In addition to
those, I'd recommend adding a new final sentence to the section recognising
OtherXML and Unknown as exceptions to this "MUST NOT" because they are so
general. I still see problems with defining more specific error codes than
we've defined but am not sure how to describe letting people define such
codes.
** Separately, I'm recommending adding wildcard support to all ebXML SOAP
extension elements and those that can repeat, such as the Error element
(primarily because its a versioning mechanism we don't consistently
support). This might be a good mechanism to point to for "subcode" support.
Implementers could define new elements that clarify specific classes of
inconsistencies (for example) or they could just define a new
foreign:SubCode element.
* Replace the third paragraph of B.2.4 with words recognising that SOAP
errors may come back synchronously (over HTTP) whether or not SyncReply was
true. In fact, the words from the SOAP specification should mean soap:Fault
won't be returned asynchronously when using a synchronous communications
protocol. Our choice in this paragraph contravenes SOAP, we should just
recognise the aspects of SOAP causing somewhat inconsistent "async over
sync" behaviour. I'm not even sure it's inconsistent from our point of
view: SOAP is another communication protocol, like TCP/IP and we certainly
expect many TCP/IP failures to occur synchronously.
hope this helps,
doug