And more comments in line. Hopefully,
this will show up for people not using HTML readers. I'll bracket in
[].
----- Original Message -----
Sent: Monday, 19 November 2001 13:28
Subject: RE: [ebxml-msg] First editorial issues on
1.09
<<comments in-line>>
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.
<< Yes, you and I discussed
this and I agreed with you. I didn't remember discussing this
with the group. Anyone have any objections to moving 1.3
to 2.1? >>
[I
was suggesting moving 1.3 to 2 and 2 to 3 (and so on) because 1.3 concerns
itself with MIME packaging and the introductory material in 2 starts with
the contents of the SOAP message document.]
"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.
<< I thought we decided against this since
the SOAP Fault may be a situation where the MessageHeader itself is corrupt
or unreadable or undefined or violates the schema
etc.?? >>
[That's exactly why this is a note and only a
(lowercase) should.]
- 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.
<<Yes, grammatically, you
are correct. I have not been willing to make
such global changes without direction. Anyone object?
>>
- 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.
<<Please be
specific.>>
[I
don't remember how (or if) Word handles searches for values output by a
field. If it works, you should be able to find "section 4" in the
document. A quick check showed me that finding "section ^#^w" catches
a few cases. For example, lines 1804, 1818 and 1912 should
reference 4.1 or 4.1.1. Finding "section ^#)" catches a few other
cases such as line 239 and many references to section 4 when error handling
is meant. I didn't search for "section ^#.^w" but that'll catch a few
cases too.]
- 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.
<<Again, you are
correct.>>
- 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.
<<This is not editorial but I will go ahead
and change 7.4.1. This is a problem any time we add a new
flag/feature. It is appropriate to use NotSupported until CPA adds it
to their spec at which time we have to change to Inconsistent. This
causes a continuous cascading problem. I like your solution to allow
either error. Where/how shall we say
this?>>
[I
made a suggestion below. We should probably discuss this more on the
list before choosing the final wording. My suggestion is just the gist
of a potential addition.]
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