Comments on TA V1.0

[Mike Rawlins <rawlins@metronet.com>]

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
rawlins@metronet.com

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.