Re: New section for the TA document

[Karsten Riemer <Karsten.Riemer@East.Sun.COM>]

Jim,
I have re-instated the orignal TA phrase about UML being optional, instead of
my closing paragraph about UMM being optional. Let's see if we can agree on
the document in that form, even though clearly the TA phrase needs some
re-wording. The document now consists of 3 short paragraphs over and above the
current TA section, and this is the minimum we can get away with, if we are to
cover how the Specification Schema is a semantic subset of the metamodel, what
it covers, and that the patterns are a necessary companion.

-karsten





>Karsten,
>I believe I understand the goal you had in the rewriting of sec 9.2.1.
>However, I have some strong
>objections to the new perspective.
>
>1) The statement that use of UMM as optional is not necessarily true. The use
>or non use of a particular
>methodology is determined on the goal desired. The BP analysis who role is to
>define a analysis process and
>methodology would state that if one were going to develop a Business
>Collaboration specification, (Top down
>as you know it) UMM is a requirement. We should not put text into the TA that
>is contrary to a different
>viewpoint.
>
>2) There is wording that the different views of the metamodel are there to
>support the different phases of
>the UMM. This is also incorrect. The fact that the UMM now uses this
>metamodel is coincidental. The views
>are different perspectives of the same metamodel, based on the "ViewPoint" of
>the user/audience of the
>specification, dependent on whether the user is a Business Person, Domain
>Expert, Business Analyst,
>Information Modeler, System Analyst, System Integrator or Implementor. These
>viewpoints provide a set of
>semantics (vocabulary) that is familiar to each and form the basis of
>specification of the objects and
>artifacts that are required to facilitate business process and information
>integration and
>interoperability.
>
>3) My understanding of the Specification Schema was to provide a mechanism to
>specify the ebXML
>business process for the "Infrastructure Release". It is providing a
>mechanism which allows for the "bottom
>up" specification approach and a possible point of integration of the "top
>down" approach. In the TA, this
>new section positions it as a competition to the use of UMM, thus inferring
>that it is the required
>approach.
>
>4) In the end of the section, the reference to mandating the use of UML was
>dropped or changed to making
>the use of UMM optional but recommended. Again, this may/does not reflect the
>view of others in the BP
>Team. Originally, this section was trying to say that use of UML, as a formal
>specification language
>(remembering that we are talking about syntax and semantics, not notation
>(diagrams)) was mandatory and not
>saying anything about a methodology.
>
>I would recommend that we simply clean up the section a little (there are
>inconsistencies in terminology)
>and leave it as is. Currently it does not preclude the different perspectives
>and at a high level explains
>what we are doing. If we must include the level of detail that you have
>included, then we must do so from
>each perspective and I suspect supply some rationale. I would rather do this
>in each respective document or
>specification. If we must do it here, then we have a lot more to do.
>
>Also we may want to a simple statement about the Infrastructure Specification
>without postioning it against
>other perspectives.
>
>I guess I am asking, how detailed must this section and how much wiggle room
>can we give ourselves.
>
>Respectfully,
>Jim Clark
>
>PS: I am also working on the ebXML Collaboration Communication Reference
>Model, which defines the logical
>(software) layers that provide for the definition of responsibility and
>seperation of concerns. I have more
>than enough, for the TA, but again I am wondering about the level of detail
>in the TA doc. I would rather
>make reference in the TA and leave the details in the specification.
>
>Karsten Riemer wrote:
>
>> Hi,
>> I have grabbed pieces from the current TA doc, pieces from Jim Clark's
>> metamodel specification doc, and pieces from my original TA proposal to
>form
>> the attached replacement for section 9.2.1. in the TA v0.94.01.b
>>
>> Please let me know if you have any issues with this.
>> If not, I will send it to TA group for inclusion.
>>
>> This satisfies one of the two pieces we had promised TA.
>> The other is an explanation of software tiers to support Business
>> Transactions, vs. those to support Business Collaborations.
>> Bob Haugen, do you want to take a stab at that, since you were the one who
>> asked for it.
>>
>> I will now cut and paste from the attached doc into Jim's specification
>> document to make sure wording is consistent both places.
>>
>> thanks,
>> -karsten
>>
>>   ------------------------------------------------------------------------
>>                                                Name:
>MetamodelArchitectureRevisedAgain.zip
>>    MetamodelArchitectureRevisedAgain.zip       Type: Zip Compressed Data
>(application/x-zip-compressed)
>>                                            Encoding: BASE64
>>                                         Description: WinZip

WinZip