[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