Subject: Comments on TA V1.0
Here are my comments in text format. -- Michael C. Rawlins, Rawlins EC Consulting http://www.metronet.com/~rawlins/
Comments on ebXML Technical Architecture Specification V1.0 Michael C. Rawlins Rawlins EC Consultin firstname.lastname@example.org Line Range: Comment: Rationale: Suggested Change: ------------------------------------------- Line Range: All Comment: A vast improvement over the version I reviewed last summer Rationale: More cohesive - contains all of the items essential for an architecture. Suggested Change: None Line Range: 198-198 Comment: phrase "proporietary integration approaches" in the context of EDI is unclear, since EDI syntax is not-proprietary. I'm not sure what you intend to say here. Rationale: Statement is confusing, and obscures the rationale. Suggested Change: Clarify your meaning. Line Range: 190-216 Comment: Lacking in several customary items usually listed as design goals. Also lacks explicit mention of SME's, though they are mentioned by implication. Rationale: Need more detail. Suggested Change: Add explicit mention of SMEs. Add other design goals, specific to the architecture in particular and not just overall ebXML, such as scalabilty, easily implementable, standards based. Or, include reference to particular goals or sections of Requirements Specification. Line Range: 275-275 Comment: Bad grammar Rationale: Bad grammar Suggested Change: From "that the company is able to engage in" to "in which the company is able to engage". Line Range: 289-289 Comment: bad wording? Rationale: meaning unclear Suggested Change: change "who it wants" to "how it wants" Line Range: 397-397 Comment: Naive statement Rationale: May leave bad impression on reader. SMEs probably won't develop models (industry goups of SMEs might) Suggested Change: Omit "SMEs" Line Range: 454-454 Comment: need possessive sense Rationale: grammar Suggested Change: change "stored in it business profile" to "stored in its business profile" Line Range: 649-650 Comment: A mandate to use a specific modeling technique and language, i.e., UML, does not ensure a consistent methodology. Rationale: Statement is inaccurate. Suggested Change: Omit this statement, or change methodology to some other phrase that indicates your intention. Line Range: 662 and 667 - may be other instances Comment: I think you mean business process description or specification, and not just business process Rationale: Clearer meaning. Suggested Change: Add "specification" after "business process" Line Range: 682-684 Comment: This statement is confusing. Rationale: Remove confusion. Suggested Change: I don't know what you intend here, so don't have a specific change. You need either more rationale and explanation for this statement, or need to remove it. On the face of it, it seems to be contradictory to say that the interfaces are outside the scope of ebXML. Line Range: 845 and 874-875 Comment: These statements appear to be contradictory. Rationale: Causes confusion and ambiguity. Suggested Change: I think you mean "transport" in 845 in the sense of a network stack (transport and the layers beneath it). Clarify that this is the sense in which transport is used. May also want to add in the same sentence that the transport *mechanism* is ebXML messaging, which is itself independent of the underlying network protocols as indicated in figure 16. Line Range: 961-969 Comment: This seems to indicate that the messaging service layer is responsible for enforcing "rules of engagement" regarding the business processes and particular documents that trading partners use. Rationale: Clarify technical intent. Suggested Change: I may be wrong, but being payload neutral, I don't think that the messaging service is responsible for enforcing business rules of engagement (rules related to the BOV). If this is the case, you need to explicitly state that the messaging service enforces certain of the FSV rules, but not the BOV rules. Line Range: ALL Comment: Reqirement not met. Rationale: Need to meet requirement Suggested Change: ebXML Requirements Specifiation states that architecture must: "Provide design guidelines for ebXML compliant messages" This is not addressed in this version. Need to address it. Was this omitted by error in this version, or is it a separate document? Line Range: ALL Comment: Though a vast improvement over previous versions, I still have reservations about the architecture adetuately meeting the overall goals for: enabling interoperability between dissimilar, but ebXML compliant, XML implementations, supporting compatibility with existing Technology and EB standards and practices simplicity provide basic, low cost solutions appropriate for SMEs support ad hoc, informal exhanges minimizes costs for development, maintenance, and use Rationale: Need to meet requirements. Suggested Change: None at this point, since we are a bit late in the cycle. I will not vote against the document on this basis, but want to go on record with these reservations.
eList eXpress LLC