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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: FW: Consolidated list of comments on the Ver 21C spec

-----Original Message-----
From: Ralph Berwanger [mailto:rab7067@earthlink.net]
Sent: Wednesday, October 11, 2000 10:18 AM
To: ian.c.jones@bt.com; maw2@daimlerchrysler.com; richard drummond
Subject: Consolidated list of comments on the Ver 21C spec

    The attached files contain all the comments that I have received regarding version 21c of the Messaging Service Specification.  I have referenced the messages when the comments were lengthy or when the message was required to clarify the comment.  It is in HTML and Excel for all the non-Microsoft users.
Ralph Berwanger
Sr. Consultant
(703) 530-0286
Reference Submitter Comment Source
Sect 8.2 para 5 Mike Leditschke change 'to he' to 'to the' email dated 10/1
Sect 8.3 Mike Leditschke replace '???' with reference email dated 10/1
Section 8.4.4 Mike Leditschke text and schema (A.2) refer to an attribute but example uses an element email dated 10/1
Appendix A.2 Mike Leditschke Schema needs a targetNamespace attribute of  "http://wwwebxml.org/namespaces/messageHeader" email dated 10/1
Appendix B.1 Mike Leditschke Example uses a default namespace which implies the schema should specify qualified elements. Preference- leave schema alone, not use a defaulat namespace in example, prefix the ebXMLHeader element with say "hdr." and add a namespace definition for "hdr' on the ebXMLHeader element. email dated 10/1
Appendix B.1 Mike Leditschke Should ebXML be providing a URL for its schemas to which instance documents can be pointed via a schemaLocation attribute? email dated 10/1
use of version attribute Mike Leditschke Concerns over the use of a version attribute for providing "future versioning capabilities". The XML schema spec talk only of parsers using namespaces and schemaLocation attributes as a means of locating the appropriate schema--no mention of version attribute nor the semantics attached to them.   COMMENT email dated 10/1
182, 212-215, 220, 244-247, 304-306 Warren Buckley Make content-length optional.  In a nutshell, the requirement to include Content-Length in the Message, Header and Payload Envelopes means that any sender must 1) calculate the lengths and 2) have enough buffer space to hold the content before sending. I believe this will have an adverse effect when it comes to implementing processes that create, route and receive ebXML messages. email dated 10/5
Line 172 Henry Lowe modify text toread "XML or other document(s) for the ebXML Payload" email dated 10/6
Lines 185-195 Henry Lowe Replace "For example" with "It must be" email dated 10/6
Lines 221 - 278 Henry Lowe Text does not completely match figure 2.1 The finugre does not have a label on the 'Container'. In fact, the light and dark gray shaded boxes are the container and should be labeled in the figure. email dated 10/6
Lines 267-269 Henry Lowe In the example, Context-Type does not have ites attributes version and charset specified.  The text of section 2.3.3 says they MUST be present. email dated 10/6
Lines 283-284 Henry Lowe The Payload Container can carry more than one   document by having appropriate references in the Manifest.  It would be useful if something to this effect were added to this section, probably in this paragraph.  Suggested text: "The Payload Container may contain more than one document and the Message Manifest provides references which allow documents to be distinguished." email dated 10/6
Line 297 Henry Lowe The text "This is the implementor's decision" implies it is entirely up to the implementor as to whether (s)he wants to carry multiple documents and how it is done.  This isn't quite the case as the Document Reference, section 3.2.1, is the standardized method for distinguishing multiple documents.  A   statement to this effect and reference to 3.2.1 should be added.  It might, also, be nice to add another example in 3.2.1 illustrating the case for multiple documents in the same payload container. email dated 10/6
Line 326 Henry Lowe It is not clear what this means.  Explanation should be added. email dated 10/6
Line 403-416 Henry Lowe I thought we had agreed that PartyID would be a URI.  This section should be updated accordingly. email dated 10/6
Line 412-414 Bernd Eckenfels I would allow the PartyID Element to occur multiple times, so you can give all the known contexts. This will enable us to se a DUNS Number, a ILN Number, a TAX Code a Company Name, a e-mail Address, a van mailbox id and so on. This is especially good for routing. email from David Burdett dated 10/9
Line 451-453 Bernd Eckenfels if there is no earlier message we should require the element to be not present, not to be empty. Or if we want to have it empty but present, then we should tell this explicitely: if there was no former message the ELEMENT has to be present and be empty </ RefToMessageID> or <RefToMessageID></RefToMEssageID>. Personally I think we should require the element to be skiped if it is empty. We should also define what kind of message we are referencing to: a order change can reference to the order send or it can reference to the order-dis-acknowledgement of the partner. PErhaps we should allow the RefToMessageID to be repeatable and add an additional Attribute: context= email from David Burdett dated 10/9
Line 460 Bernd Eckenfels we should state who will interpret the ReliableMesssageInfo field and what he should do with it. In the enumeration we should also add the "AtLeastOnce" or something like this. Cause this is the normal way transmission protocols without duplicate checking will work (SMTP for example). Filtering duplicates should be responsebility of the endpoints. email from David Burdett dated 10/9
Line 551-591 Bernd Eckenfels i would allow the following elements to be optional: (the > reason for this is it is better to allow them to be removed than everybody is making something "up" to fill in them. TPAInfo, ReliableMessageInfo, ServiceInterface , Action, ConversationID, make RefToMessageID (0-n)=* email from David Burdett dated 10/9
Appendix B.1 John Neve The example does not implemtn the proposed structure email dated 10/10
Line 634 John Neve Why not allow multiple receivers email dated 10/10
Sect 2.2.1 John Neve Are we sure there is a business justification in AtMostOnce value? email dated 10/10
Sect 2.2.2 John Neve Shouldn't there be a value with meaning 'at least 1, and if more, other occurrences must bear a Possible Duplicate Flag with reference to previous attempts? email dated 10/10
Line 663 John Neve There should be more that 1 RefToMessageID email dated 10/10
Sect 2.4.1 John Neve BusinessServiceInterface - multiple occurrences should be allowed email dated 10/10
Sect 2.5 John Neve Action Multiple occurrences of ServiceInterface should be allowed email dated 10/10
Sect 3.1.1 John Neve A TestLiveMode flag with value Test or Live should be added email dated 10/10
Sect 3.1.2 John Neve see comments for list of proposed additions to spec. email dated 10/10
Sect 7.2.1 Gait Boxman clarification regarding the use of charset attribute. Submitter believes we have used it in error. email dated 10/10

Comments on ver 0.21c.xls

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC