Added by gunther.stuhec, last edited by gunther.stuhec on Apr 10, 2007






Line 99 - 101 (in 3.2 Scope and Focus) and 171 -173 (in 4. Overview)  are almost identical:


These applications may use Internet and Web based information exchanges as well as traditional Electronic Data Interchange (EDI) systems. The exchanges may be service oriented as in Web Servicesor be Peer-to-peer.


Electronic messaging may be implemented as Peer-to-peermessaging (e.g. by means of an ISO 15000-1 ebXML Messaging Service), or Service Oriented as a Web Service.

Proposal: reduce redundancy (btw: I believe Internet and Web are perceived as synonyms nowadays (although, of course, internet is the technology and Web the application - so Web based information exchange would be sufficient)  



Line 109:

The Core Component Message Library is to be stored in a UN/CEFACT repository and identified in an ebXML compliant registry.

I just wonder whether there is an ebXML compliant registry available for practical use. If not, this sentence would make any Message Library invalid, which is stored in a repository but not registered , wouldn't it?



Line 182:

This technical specification defines the structure of Business Messages in an abstract; syntax neutral way, as a model (a UML class diagram) that can be used to serialize information in various concrete syntaxes, such as XML (Extensible Markup Language, a W3C Recommendation) and UN/EDIFACT (ISO 9735).

I believe, we must clearly distinguish between the syntax (XML, ISO-9735) as a meta-language and its application. Speaking of UN/EDIFACT implies not only the syntax but the existing directories with their semantics etc. As the name of the initial project indicates (ebXML) the main focus of the task is to develop standardized usage of XML. Especially message assembly in EDIFACT is - due to the syntax - far more complicated as deriving XML from CCTS.


I would recommend, to stop the sentence after " .. serialize information in various concrete syntaxes."



Line 188 (Picture)

Although line 178..180 says "This technical specification will focus on the Business Information in a Business Message, and will not include the specification of any envelope information needed to transmit this information." the picture refers to a CCMA - Envelope. I'd prefer to refer to this block as CCMA - Business Message - which would be coherent with picture on line 221 (Business Message Type) and tiles in chapter 5 and 6.



Line 214:

 Message Assemblies inherit their structure and definition from Aggregate Business Information Entities.


Unfortunately, I completely disagree with this statement: if we would include this requirement, we are caught  in a trap: an ABIE requires an ACC (see line 245). Since there is no "Universal Line Item" or universal "Message" structure, one would need an ACC for each individual message assembly or even the sub-assemblies. So there must be an ACC Invoice. Details, Orders. Details etc. The first and major problem is, this is not longer a semantically neutral building block - as ACCs are supposed to be. 


And it is probably an illusion to hope, one structural design (ACC) could cover all the different implementation requirements for a message type derived of various process scenarios.


Line 169 says: "Business Messagesmay even be assembled on-the-fly in an operational process, e.g. to support query and response dialogs." In that case, obviously only fragments of information will be exchanged in that dialog, none of them perhaps forming a complete "standard document" but being meaningful in the process of  "negotiation" and at the end of a dialog a situation is achieved as one would get with complete documents (e.g. Booking request for a container load on a vessel and booking confirmation from the carrier )  I wonder how that can be achieved with the requirements of having ACC for each message assembly construct.


And finally, as far as I know, all UN/CEFACT projects that have dealt with messages (Cross Industry Invoice and other in TBG1, UneDocs - TBG2 ...) have used assembly components which are NOT based on ACC. According to my knowledge, due to the fact that it is simply  not feasible.


I propose to change line 214 as follows:

Message Assembly Components put together  ABIE in a meaningful structure to form a complete Message Assembly or a suitable sub-structure to support a distinguished business process. Additionally they may have Action and Intention codes as attributes and a sequence number to indicate in what order the Message Assembly appears in the Business Message or in the higher level Message Assembly. ...


and to delete the generalization association from Message Assembly to Aggregate Business Information Entity (picture line 221)

and to delete line 245.. 246 and 328 ..332



Jörg Walther

Editing team member