commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SCXML-196) Redefine SCXMLSemantics to align with the Algorithm for SCXML Interpretation as described in the SCXML specification
Date Thu, 03 Apr 2014 07:05:14 GMT

     [ https://issues.apache.org/jira/browse/SCXML-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ate Douma updated SCXML-196:
----------------------------

    Description: 
One of the targets for the Commons SCXM 2.0 roadmap milestone 1 is to redefine SCXMLSemantics
to align with the SCXML Algorithm for SCXML Interpretation, see: http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation
The current SCXMLSemantics interface and its implementation is so much different from the
algorithm in the specification that 'molding' it into what the algorithm now expects is too
cumbersome.

The current SCXMLSemantics and its implementation will therefore be completely replaced with
a new one, closely corresponding to the semantics of the SCXML Algorithm in the specification.

The algorithm described in the specification leaves plenty of room for optimization and choice
of techniques.
For a first cut implementation though I intend to simply follow the described algorithm as
close as possible, also to make sure not to deviate from the specification already too early
:)
After the new implementation has been tested and validated to be conforming the expected behavior,
or even later than that, the implementation surely can be refined and optimized further.

The changes needed for this task are closely related to those described in SCXML-197: Better
separation of concern between SCXMLExecutor and SCInstance and introducing a new SCXMLExecutionContext.
Although through SCXML-197 already many improvements are realized, to be able to implement
the new SCXMLSemantics requires additional (major) changes, which functionally should be regarded
part of SCXML-197, but cannot be committed separately as the changes are too closely related.
I'll therefore update SCXML-197 describing those functional changes regarding the better separation
of concerns, although they will be committed against this issue.

An important note is that with the re-implementation of the SCXMLSemantics, the static SCXMLHelper
class, as well as the (Transition) Path helper class functionalities will be completely 'absorbed'
into the model and the new algorithm implementation. These classes therefore no longer are
used and needed and will be removed. 
Furthermore, the Step class now only is used from within the SCXMLSemantics implementation
and therefore moved to the semantics package.

With these changes in SCXML-196 and SCXML-197, the goals for Milestone 1 on the roadmap to
SCXML 2.0 have been completely met and I'll create a milestone 1 svn tag for it shortly. 


  was:
One of the targets for the Commons SCXM 2.0 roadmap milestone 1 is to redefine SCXMLSemantics
to align with the SCXML Algorithm for SCXML Interpretation, see: http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation
The current SCXMLSemantics interface and its implementation is so much different from the
algorithm in the specification that 'molding' it into what the algorithm now expects is too
cumbersome.

The high-level plan I have is to:
- fork SCXMLSemanticsImpl to SCXMLSemanticsImpl2, without implementing SCXMLSemantics
- fork SCXMLExecutor to SCXMLExecutor2, extending SCXMLExecutor
- switch to use SCXMLSemanticsImpl2 explicitly in SCXMLExecutor2
- start with simply implementing the SCXML Algorithm from 'scratch' in SCXMLSemanticsImpl2
using (top level) methods matching those described in the algorithm and refactor SCXMLExecutor2
to leverage this

With the above initial steps, the existing implementation will stay in place and remains available
to compare and test the new implementation against.
There probably will be need to make accommodating changes in other areas, which I will try
to keep compatible with the existing implementation or at least not to break it.
The reason to fork and extend SCXMLExecutor is that it is referenced and used in many other
places (that is: currently), like in SCInstance. By extending it, the SCXMLExecutor2 can still
play that role without directly breaking everything.

The algorithm described in the specification leaves plenty of room for optimization and choice
of techniques.
For a first cut implementation though I intend to simply follow the described algorithm as
close as possible, also to make sure not to deviate from the specification already too early
:)
After the new implementation has been tested and validated to be comforming the expected behavior,
or even later than that, the implementation surely can be refined and optimized further.
That also will be time to decide to drop and replace the existing SCXMLExecutor and SCXMLSemantics
(both interface and implementation) with the new versions.



> Redefine SCXMLSemantics to align with the Algorithm for SCXML Interpretation as described
in the SCXML specification
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: SCXML-196
>                 URL: https://issues.apache.org/jira/browse/SCXML-196
>             Project: Commons SCXML
>          Issue Type: New Feature
>    Affects Versions: 2.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0
>
>
> One of the targets for the Commons SCXM 2.0 roadmap milestone 1 is to redefine SCXMLSemantics
to align with the SCXML Algorithm for SCXML Interpretation, see: http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation
> The current SCXMLSemantics interface and its implementation is so much different from
the algorithm in the specification that 'molding' it into what the algorithm now expects is
too cumbersome.
> The current SCXMLSemantics and its implementation will therefore be completely replaced
with a new one, closely corresponding to the semantics of the SCXML Algorithm in the specification.
> The algorithm described in the specification leaves plenty of room for optimization and
choice of techniques.
> For a first cut implementation though I intend to simply follow the described algorithm
as close as possible, also to make sure not to deviate from the specification already too
early :)
> After the new implementation has been tested and validated to be conforming the expected
behavior, or even later than that, the implementation surely can be refined and optimized
further.
> The changes needed for this task are closely related to those described in SCXML-197:
Better separation of concern between SCXMLExecutor and SCInstance and introducing a new SCXMLExecutionContext.
> Although through SCXML-197 already many improvements are realized, to be able to implement
the new SCXMLSemantics requires additional (major) changes, which functionally should be regarded
part of SCXML-197, but cannot be committed separately as the changes are too closely related.
> I'll therefore update SCXML-197 describing those functional changes regarding the better
separation of concerns, although they will be committed against this issue.
> An important note is that with the re-implementation of the SCXMLSemantics, the static
SCXMLHelper class, as well as the (Transition) Path helper class functionalities will be completely
'absorbed' into the model and the new algorithm implementation. These classes therefore no
longer are used and needed and will be removed. 
> Furthermore, the Step class now only is used from within the SCXMLSemantics implementation
and therefore moved to the semantics package.
> With these changes in SCXML-196 and SCXML-197, the goals for Milestone 1 on the roadmap
to SCXML 2.0 have been completely met and I'll create a milestone 1 svn tag for it shortly.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message