Re: Comments on TA V1.0

[duane <duane@xmlglobal.com>]

Mike Rawlins wrote:
>
> 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".
>>>>>>
Mike:

It was written in Canada - what do you expect???  ;-)

Thanks for all the great feedback and encouragement.  Brian and I will
be finishing the document next week.  We will give you a page with the
disposition of your comments.

Cheers

See you in a few weeks

DUane

 
> 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.