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


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
begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:jdc-icot@lcc.net
fn:James Clark
end:vcard


[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