[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC