OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Final voting reminder


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.



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.

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.

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.

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.

5) line 26 If the section is preserved (see issue 4), then

6) line 200 s/sending and receiving/that sends and receives/

7) line 208 s/,//

8) line 214 s/Elements/Features/

9) line 472 s/the following figure/figure 2.1/

10) line 509 s/may/can/

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.

12) line 724 s/The /The URI /

13) line 732 s/The /The URI /

14) line 764 s/must/MUST/

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, ...

	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

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.

18) line 831 s/schema/scheme/

19) line 872 We thought that an issue had been raised that challenged
	the "local part" characterization.

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.

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.

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

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.

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)

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. The
	Description element MUST not be empty as it extends

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.

	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/

28) line 1037 s/and //

29) line 1050 s/for the ebXML Message Service//

30) line 1434 This was supposed to have been changed to MUST.

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.

32) line 1449 s/SHOULD/MUST/

33) line 1459 s/structures/extension modules/

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

35) line 1564 s/This/The/

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.

37) line 1809 URI s/b urn:oasis:names:tc:ebxml-msg:service

38) line 2054... this is essentially duplicate of the content of
	section 11.1.4, suggest it be deleted.

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).

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
	Suggest restoring that inline documentation.

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

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  (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.

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).

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC