Workflow languages comparison
The chart (see title's link) comparing UML/BPML etc. capabilites has helped me realize one of the benefits of OpenACS using tcl language. Hard-coded workflows are easily modifiable at the admin level. Using a meta language for actually programming the workflow is not necessary and introduces unnecessary complexity and meta-language level limitations.
The porting of sql-ledger and OpenACS ecommerce package as ecommerce-g2 is requiring the integration of both workflows. The combined workflows could use the OpenACS workflow package where users participate in the process, but the package adds a layer of abstraction which makes debugging and modifying workflow much more difficult for OpenACS admins. For example, the bugtracker has a much simpler workflow, yet workflow related problems can still plague some implementations.
For ec-g2 to work well, the ecommerce and accounting business applications need to remain transparent and changeable according to different workflow conditions, yet remain stable and fixed once a workflow pattern is established. The tcl code provides admin level flexibility and auditing without introducing aspects that could be vulnerable to a db level exploit.
To the extent that the code requires a robust (and fixed) workflow, the workflow shouldn't be modifiable by a workflow package anyway. So, the workflow package won't be used for the accounting aspects of ecommerce-g2. This is consistent with sql-ledger's workflow which provides access via roles and functional context. In OpenACS, roles are identified as groups of a specific group-type and context is a function of url/page yet much more flexible (see groups and permissions: http://openacs.org/faq/one-faq?faq_id=122349#316321 ).
--Torben