All,
It is with deep regret that I must vote AGAINST adoption
of v2.0 of the ebMS specification as an OASIS TC Specification
unless the issues recently raised on the list
as well as those below and a few others that Doug and I will
be submitting before the end of the week are addressed.
While many are editorial or typographical in nature,
there are a number of substantial technical issues
which we believe are critical enough to warrant a vote
AGAINST unless, and until, they are formally addressed by
the TC.
Given that this specification is intended to be submitted
for consideration as an OASIS standard, we feel strongly that
it is important to get it right rather than simply
say we're done.
Cheers,
Chris
1) line 15/16 the date cited here should be consistent
with its adoption as a TC, not the date that the
document was published to the TC for consideration
(vote). Given that the ballot is closed as of
January 18, then the date cited here cannot be
less than that date.
(editorial)
2) line 17/18 either the tense is incorrect (is presented)
or this should be removed. Suggest that the latter be
applied. In the event that the OASIS membership
does approve the TC specification as an OASIS Standard,
then I could see adding something to that effect.
(editorial)
3) line 20 need to update the URI reference here. Should follow
w3c approach and have a stable URI that people can reference
which will always have the latest draft, in addition to an
explicit URI for the specific reference to a specific draft
for use in external references, etc.
(editorial)
4) line 23 I agree that having this section (ebXML Participants)
in addition to the one in the appendix is both gratuitous
and confusing. Suggest that we have but a single list, and
that that list be in an appendix, if anywhere. There is
no reason to cite the participants of the original ebXML
project team.
(editorial)
5) line 26 If the section is preserved (see issue 4), then
s/meeting/meetings/
(editorial)
6) line 200 s/sending and receiving/that sends and receives/
(editorial)
7) line 208 s/,//
(editorial)
8) line 214 s/Elements/Features/
(editorial)
9) line 472 s/the following figure/figure 2.1/
(editorial)
10) line 509 s/may/can/
(editorial)
11) line 709 this is going to lead to all manner of confusion.
For conformance to THIS specification, all of the version
attributes on any SOAP extension elements defined in THIS
specification MUST have a value of "2.0".
An ebXML message MAY contain SOAP header extension elements
that have a value other than "2.0". An implementation
conforming to this specification that receives a message
with ebXML SOAP extensions qualified with a version other
than "2.0" MAY process the message if it recognizes the
version identified and is capable of processing it. It
MUST respond with an error (details TBD) if it does not
recognize the identified version.
(technical)
12) line 724 s/The /The URI /
(editorial)
13) line 732 s/The /The URI /
(editorial)
14) line 764 s/must/MUST/
(editorial)
15) line 784 use of the term OPTIONAL here may be confusing
given the conformance statement. Suggest that this be
rephrased as follows:
The Role element, if present, ...
(technical/editorial)
Other instances of OPTIONAL where ordinality is meant:
* 500 (MIME start parameter)
* 1801, 1814 (Signature element in Message Status
Request & Response)
* 1822, 1842 (StatusRequest and StatusResponse
elements; really, the service is OPTIONAL)
* 1905, 1955 (Signature element in Ping & Pong)
16) line 788 suggested replacement text for the Note:
Note: Use of a URI for the value of the Role element
is RECOMMENDED. e.g. http://rosettanet.org/roles/buyer
(editorial)
17) line 810 given that we agreed in the f2f that there *was*/*is*
a CPA, this sentence should be removed so as to avoid any
unnecessary confusion.
(technical)
18) line 831 s/schema/scheme/
(editorial)
19) line 872 We thought that an issue had been raised that challenged
the "local part" characterization.
(editorial)
20) line 899 While it may be true that in order to ensure that
duplicates are detected and prevented from being forwarded
to the application, a persistent store is required,
it is not a request by the sender that
the receiver have a persistent store, it is a request by
the sender that the receiver filter duplicate messages
such that the application does not receive them.
This section needs a better description.
(editorial)
21) line 901 This too is going to be confusing to the reader.
The semantics of duplicate elimination are such that the
application that is to process the received message need
not concern itself that it might be processing a duplicate
message. The delivery semantics of this element alone might
be either at-most-once or best-effort, but in conjunction
with acknowledgments, retries, etc., can effect delivery
semantics of once-and-only-once.
(technical)
22) line 903 "if there is a CPA with ..." is a little too vague.
This is related to the issue raised recently on the list[3].
We prefer that we be a bit more specific. Suggested text:
The DuplicateElimination element MUST NOT be present if
the DeliveryChannel for the message in the CPA identified
by CPAId has a value of "never". The DuplicateElimination
element MUST be present if the DeliveryChannel for the
message in the CPA identified by CPAId has a value of
"always".
(editorial)
23) line 914 (example) curious that the From party has no
identified Role, but the To party does. Suggest that
both be assigned a role or neither.
(editorial)
24) line 942 this sentence seems premature since xlink:role is
an attribute of Reference element which has not yet been
defined. Suggest moving this sentence to the bullet
defining xlink:role below (after line #961)
(editorial)
25) line 972, 1321 The Description element defined in section 3.1.8
identifies the purpose of the Description element as
describing the message. The Description element here
is intended to provide for a description of the payload
document identified by the Reference item. The
structure/syntax of the element may be the same, but
the purpose is quite different.
Suggest that we reference the structure of the description
element, but that we augment the definition here (and
elsewhere throughout the spec) with the specific purpose
of the element in the current context.
In addition, the definition of the Description element
at times conflicts with the schema (esp sect. 4.2.3.2.6). The
Description element MUST not be empty as it extends
non-empty-string.
(technical)
26) line 982 Chris previously sent a note suggesting that this
Note be discarded. It isn't at all clear that it adds
any value.
(editorial)
Would add to text (or note) in section 3.2.2 that the
xlink:href may be a Content-Location or a Content-ID
as described in section 4.1.3, lines 1084-1089.
If the ds:Reference element may have a URI of this
type and that URI must match the xlink:href of some
"corresponding" eb:Reference element, options must
be similar.
(minor technical)
27) line 1029 s/may be/is/
(editorial)
28) line 1037 s/and //
(editorial)
29) line 1050 s/for the ebXML Message Service//
(editorial)
30) line 1434 This was supposed to have been changed to MUST.
(technical)
31) line 1436 The method of duplicate elimination is not achieved
via a persistent store, but is facilitated by same.
The mechanism by which duplicates are detected and
eliminated is via the MessageId. This is likely
to become a source of confusion.
(editorial)
32) line 1449 s/SHOULD/MUST/
(technical)
33) line 1459 s/structures/extension modules/
(editorial)
34) line 1512 We agreed that an error message could be sent
reliably. You are only precluded from requesting an
acknowledgment on a message that itself is an acknowledgment
message.
(technical)
35) line 1564 s/This/The/
(editorial)
36) line 1580 Again, we did NOT agree to this at all. We
agreed that an Error message *could* be sent reliably.
Ref [4] for discussion.
(technical)
37) line 1809 URI s/b urn:oasis:names:tc:ebxml-msg:service
(technical)
38) line 2054... this is essentially duplicate of the content of
section 11.1.4, suggest it be deleted.
(editorial)
39) line 2791... references to ebXML specs should be qualified by
their URI, and as previously cited, the ebRS reference
should probably cite the 2.0 version of their spec(s).
(editorial)
Issues with the msg-header-2_0.xsd schema follow.
40) 2245(95): Comment from last draft-msg-header-05.xsd had a useful
annotation mentioning the soap:actor element in
SyncReply MUST have the value
http://schemas.xmlsoap.org/soap/actor/next
Suggest restoring that inline documentation.
(editorial)
41) 2281(125): Doug raised an issue[1] that the Acknowledgment/RefToMessageId
element should be removed. It remains in the document and
the schema but should be removed. An Acknowledgment element
should be included if and only if the overall message
refers to the original one of interest.
42) 2282(126): Doug believes he mentioned this before w.r.t. the document.
The Acknowledgment/From element is not particularly useful
because it provides the Receiving MSH no actionable information.
Since the current hop-to-hop text doesn't require messages
to follow the same routes inbound and outbound, an
AckRequested/From element might be useful -- letting the
receiver know where to send the Acknowledgment in cases
where it must be sent separately. Probably would be better
to remove Acknowledgment/From since it covers only 1 of the 4
values hop-to-hop implementations might want to log.
Other alternative is From and To in both AckRequested and
Acknowledgment.
(technical)
43) 2304(148): Description element here doesn't match the document. We'd
much prefer leaving the schema as is and correcting the
document's poor description of this element and an
"empty content" case. None of the other Description
element occurrences in the text go so far away from
standard practice as section 4.2.3.2.6. (Probably not good
to mention w.r.t. schema at all.)
(technical, see issue 24)
44) 2338(183): sequenceNumber.type is poorly defined. The base type for
the element content must be nonNegativeInteger (not
positiveInteger) to allow the oft-mentioned "0" value.
Even better, should define a type derived from
nonNegativeInteger with a maxExclusive="99999999" attribute
and use that here (guess the attribute can be added in
the element def'n as well). Going even one step better to
avoid leading zeroes and the plus sign (as uselessly required
by the documentation), could use pattern="0|([1-9][0-9]{0,7})",
making the min and max values redundant.
(technical, base type issue is MAJOR!)
45) 2374: Why isn't the headerExtension.grp attribute group derived by
extension from the bodyExtension.grp? That would be a
bit more clear.
(editorial)
46) 2397(240) & 2403(248): Role element is used twice but not defined in a common
location. Suggest defining Role at the top level and
referring to that definition here. These are the only times
<element> appears in the schema with a type attribute but
not at the top level (not defining a global element).
(editorial)
47) It was proposed [2] that the Schema element have an optional
"namespace" attribute. This was raised as a technical
issue but not addressed.
48) 2169 should reference http://www.w3.org/2001/03/xml.xsd in
the import statement instead of the "hacked" version
currently cited.
[1] http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00351.html
[2] http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00323.html
[3] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00112.html
[4] http://lists.oasis-open.org/archives/ebxml-msg/200201/msg00036.html