MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ebxml-msg] First editorial issues on 1.09
|
David,
In a quick read of 1.09, I've noticed a few things we could
get started on resolving. Some are rather picky (sorry).
- The text in section 1.3 has not moved into Part 1. This
is not introductory material but the first plank in the standard we're
defining. During the meeting last week, we agreed (after little
discussion) to move this material later in the document. This should
primarily be a renumbering of the section to a new section 2 just after the
Part 1. title.
- The new text does not resolve issues Arvola raised in the
week prior to our meeting with regards to the SOAP Fault element and revolving
which message was in error. I suggested (in http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00211.html)
"Note: A SOAP Fault element on its own may not provide the
requesting MSH with the context necessary to identify the message in
error. An MSH returning a SOAP Fault should include ebXML
MessageHeader and ErrorList SOAP extensions in the same SOAP message.
This would be especially useful when the error is returned
asynchronously."
but don't see it in the document.
- Please search the document for the word "that". Almost
all instances (especially in the phrase "that is" which can be globally
deleted with allowance for commas) can be removed.
- Most references to top level sections should refer to a
specific sub-section. For example, references to section 4 occur when
the issue is security, errors, some specific element, et cetera.
- It's up to you whether the document uses a comma prior to
"and" and "or" but the current document is not consistent in this
respect. It doesn't appear commas are added for "more complex" sentences
for example.
- A bit more on errors should be primarily editorial: The
current text is inconsistent with respect to what error should occur under
different situations. For example, a conflict with the CPA is handled
using an Inconsistent Error but the description of Inconsistent doesn't cover
anything except elements and attributes in the document at hand.
Specific inconsistencies (such as duplicateElimination in 7.4.1) are sometimes
handled using a NotSupported error.
Perhaps this last point isn't an editorial issue? We're
requiring a specific and inconsistent processing order at the receiving
MSH. Most issues around features supported by the MSH are captured in the
CPA. Whenever we see "NotSupported" meaning a feature was requested the
recipient couldn't handle, an "Inconsistent" error would be just as
appropriate. At the moment, the order is 1) check support for
duplicateElimination and a few other things 2) check CPA 3) recheck CPA against
requested features (even if they're entirely unsupported).
It's up to an enterprise how free they want to be with their
supported feature list. A worried company with a public ebXML service
might report everything as inconsistent (with a default CPA they've published to
the world). We shouldn't preclude that mode of operation. I'd
recommend allowing either error in all situations. The easiest way to do
that would be to use "Inconsistent" throughout the document but include
explanatory material in 4.2 stating that many inconsistencies with a CPA ("as
described elsewhere in this document") may also result in a NotSupported
error.
thanx,
doug
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC