OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: New section for the TA document


Jim,
you are right,
here is the correct document,

-karsten

>Karsten,
>
>I think you sent out the wrong doc.
>
>Jim
>
>Karsten Riemer wrote:
>
>> 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
>>
>>   ------------------------------------------------------------------------
>>                                         Name:
>SpecificationSchemaRevised.zip
>>    SpecificationSchemaRevised.zip       Type: Zip Compressed Data
>(application/x-zip-compressed)
>>                                     Encoding: BASE64
>>                                  Description: WinZip

WinZip



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC