[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: TA issues - was: [Revised Messaging Services Section for TA spec]
Comments included under <Nikola-Response>. <Issue 1> <Nikola> I think that "The View" that we have as figure 1.0 is appropriate and serves the right purpose. As any high-level abstraction it only conveys some aspects of the whole system. I would certainly leave it as it is and try to put some other "System Views" in addition to this one. </Nikola> <Chris> I think that it needs to be reworked on a number of levels. Firstly, it is (IMHO) quite distracting. I would prefer that it be toned down a bit. I don't think that the working groups need to be represented in the figure. I think that it should focus on the components which they are defining and their interface points/interactions. </Chris> <Nikola-Response> I agree that different models might be distracting to different people. Any model just tries to model the real world and is at its best just an arbitrary abstraction. I call "This view" a "Conceptual diagram" of ebXML. And concept of working groups is just one aspect of it. Talking about components, ... we have discussed this in the past (see attachment http://lists.ebxml.org/archives/ebxml-architecture/200005/doc00001.doc in http://lists.ebxml.org/archives/ebxml-architecture/200005/msg00018.html) and recently as well and I support that we need more of these. </Nikola-Response> </Issue 1> <Issue 2> <Chris> Secondly, it is incomplete and inaccurate (again, IMHO). - the ebXML BP metamodel does NOT define the XML transform rules. Certainly, the transform rules would be applied *to* a model described in terms of the metamodel. The metamodel is used to *describe* a business process... </Chris> <Nikola-Response> You are right. After checking the diagram again I can see that is has inaccuracies like this. I don't know how we came to this (ChangeLog?), but if you look at the earlier version of the diagram http://lists.ebxml.org/archives/ebxml-architecture/200002/msg00033.html - slide #3 you will find that this "relationships" were not there. </Nikola-Response> </Issue 2> <Issue 3> <Chris> Certainly, not all of the TP relationships have been incorporated into the figure. </Chris> <Nikola-Response> They (all) will never ever be. Also, does this contradict with your previous statemenet "that it be toned down a bit"? </Nikola-Response> </Issue 3> <Issue 4> <Chris> As far as I'm concerned, figure 1.0 is NOT an architecture diagram by any stretch of one's imagination. </Chris> <Nikola-Response> I disagree. It does show the structure, components of the structure and relationships between them (see: Desmond Francis D' Sousa, Alen Cameron Willis: "Objects,Components, and Frameworks with UML" page:482). Yes, it is not an UML Component, Packaging, Collaboration, ... notation. However, the question is: "Does it help to explain the architecture of ebXML"?. For me it does. </Nikola-Response> </Issue 4> Regards, Nikola
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC