And more comments in line. Hopefully, this
will show up for people not using HTML readers. I'll bracket in
[].
----- Original Message -----
From: David
Fischer
To: Doug
Bunting ; ebXML Msg
Sent: Monday, 19 November 2001 13:28
Subject: RE: [ebxml-msg] First editorial issues on 1.09
<<comments in-line>>
-----Original Message-----
From: Doug Bunting
[mailto:]
Sent: Monday, November 19, 2001 2:56
PM
To: ebXML Msg
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.
<< 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.]
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.
<< 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
