[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Final voting reminder
I too vote AGAINST adoption of the current specification as an OASIS TC document. Chris and I are working to document all outstanding issues from earlier issue lists and anything else we've noticed in our most recent readings of this document as quickly as possible. We look forward to working with you all to resolve these problems. thanx, doug ----- Original Message ----- From: "Christopher Ferris" <chris.ferris@sun.com> To: "Douglas Bunting" <db134722@iPlanet.com>; "Christopher Ferris" <chris.ferris@sun.com>; "Ian Jones" <ian.c.jones@bt.com>; "ebXML Msg" <ebxml-msg@lists.oasis-open.org> Sent: Tuesday, 15 January 2002 14:10 Subject: Re: [ebxml-msg] Final voting reminder 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC