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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC