Since early this year the progress and development of Commons SCXML 2.0 has
severely declined because of two major technical hurdles, and thereafter of
both motivation and lack of time:

- The SCXML XML/XPath datamodel support has been dropped from the final
W3C SCXML 1.0 specification [1], because of too many functional and semantic
complications and limitation, as well as lack of interest for implementing it.

The implementation of the XML/XPath datamodel in Commons SCXML has been
problematic for precisely the same reasons.
And not being able to provide such implementation properly by us (Commons
SCXML) actually has been one (final) argument for dropping it from the
specification...

- The implementation of the Javascript datamodel support based on the
old/outdated Rhino Javascript engine in Java 7 and below, turned out to be
quite difficult. While it turns out to be much easier and reliable, but
different, with the new Nashorn Javascript engine in Java 8+.

After bringing this first up on the user@ list earlier this week, I now want to
propose the following major changes to revive the further development towards
Commons SCXML 2.0:
- drop the support for XML/XPath based datamodel, and instead introduce a much
  easier to implement and support JSON datamodel as alternative, for all current
  Commons SCXML support 'languages': JEXL, Groovy and Javascript.
- bump the minimum Java version to 8 so we can leverage and only need to support
  the Nashorn Javascript engine

The only user response so far on user@ is fully in favor of these changes,
and both myself and Woonsan Ko are motivated to continue developing and
completing the goals for Commons SCXML 2.0 based on these changes.

If nobody here has strong arguments against the above proposal (and assuming
lazy consensus otherwise), we would like to start on these changes shortly,
before the end of the year.

Kind regards,
Ate Douma
Woonsan Ko

[1] http://www.w3.org/TR/2015/REC-scxml-20150901/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to