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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC