[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Comment
Scott Hinkelman wrote:
>I'm just mostly concerned with the terms in the narrative turning into the
>Composit Participants like "Composite" and "Leaf", but this could be
>avoided.
Yes, good names are a separate topic, and also it would be possible
to add as many specialized components (with specialized names)
as required. I'm only trying to:
a) simplify the hierarchy, so simple cases don't require unnecessary
levels of objects; and
b) make features like Ordering Rules and Constraints freely
composable wherever needed. (More on Ordering below...)
>|>Upon looking at this further, I would think that by nature
>|>the StepDefinitions are in fact a sequence within the BPD,
>|If they had OrderingRules, they could be sequenced.
>|But I am proposing to move the OrderingRules, so that any
>|Composite could have sequenced members.
>I understand. I'm just making some assumptions that at the top it is not
>needed and there is an implied sequence. Perhaps this is insufficient,
>but I'm striving for complexity onlt when needed. I'm assuming you are
>thinking to add the ordering rules at the Composite.
1. We agree on the goal "as-simple-as-possible".
2. You are probably correct about implied sequence in many cases.
3. Yes, Ordering Rules would only make sense for Composites.
So my statement once upon a time about placing all feature
associations on the top-level Component was over-simplified
if not incorrect.
>I'm only looking V2 and intention to understand how to integrate tpaML.
>The TRP group has concensous that some form of tpaML will act as
>configuration information for the Transport runtime.
I'm responding to comments on my "Composite" proposal,
but I do understand that you are also trying to merge tpaML
and the V2 metamodel. It's a little confusing, I'm sure.
That's interesting that the TRP group has decided on tpaML -
one more area that will need alignment. I'm glad you have
joined the BP discussion.
>I think you agree on the rest that was chopped.
I didn't chop it on purpose, and reposted the part that
I thought was interesting (more about overloaded names,
e.g. Transaction and Business Process. It looks like
"Contract" is running into overloaded-name problems,
too).
Thanks again,
Bob Haugen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC