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