Folks,
I'm just getting to the final details on the V2
model.
Right now the schema points FORK at
BusinessTransactionActivity.businessTransaction
Dale> I think that Fork could be semantically
constrained to link BTAs with BTAs. [At
present it is more open in that the ToLink takes IDREFs that could point to a
pseudo-state (like a Choice/Decision) as well as to a BTA. On both the
incoming and outgoing link, there is a conditionGuard and the "document
language" can (and probably should) hang on those links. So the FromLink can
transition automatically ( "true" on its condition), then each ToLink's
condition can be checked. Several can occur with the "Or" semantics. XPath
language on links is probably even more appropriate for selecting (one or
more) paths to pursue. I don't think we want to collapse the node and edge
layer of description with the boolean condition layer of description. That
would be more of an architectural change than I would be comfortable with. I
think simulation or monitoring/verification use cases would get very hard to
do.
This may make sense in the case where only
one
document outcome can occur - but I believe
it is more
accurate to point it at :
BusinessTransactionActivity.businessTransaction.RespondingBusinessActivity.document
I think historically the conditionGuard with the
DocumentLanguage has been used to make the fork branches depend on document. The same
document could be on several branches of
course.
since what is potentially happening is that
within a
BusinessTransaction exchange there are
several possible outcomes
indicated by what document(s) are returned, based
on condition
and state.
Dale> I
think you are refactoring even more that I was doing. While I see where you
are going, the exisiting BPSS has "edges" for the main potential paths, but
uses booleans to filter traversals.
As it is now - you have to split the outcomes up
into separate BusinessTransactions.
While this works - its not very
intuitive.
DW