Commons SCXML
  1. Commons SCXML
  2. SCXML-200

Normalize and complete the SCXML object model and parsing

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Labels:
      None

      Description

      The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

      I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to cleaner separate and restrict the features belonging to the right level and element.

      The current state and transition model hierarchy is like this:

      TransitionTarget 
        <- Initial
        <- History
        <- State
             <- Final
        <- Parallel
      
      Executable
        <- Transition
      

      After my restructuring it looks like this:

      Initial
      
      TransitionTarget
        <- History
        <- EnterableState -> DocumentOrder
             <- TransitionalState
                  <- State
                  <- Parallel
             <- Final  
      
      Executable
        <- SimpleTransition
             <- Transition -> DocumentOrder
      

      With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

      I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

      All these changes have a big impact on the internal API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.

        Activity

        Ate Douma created issue -
        Ate Douma made changes -
        Field Original Value New Value
        Description The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:

        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
          
        After my restructuring it looks like this:

        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        Ate Douma made changes -
        Description The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:

        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
          
        After my restructuring it looks like this:

        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:
        {code}
        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
        {code}
          
        After my restructuring it looks like this:
        {code}
        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
        {code}
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        Ate Douma made changes -
        Description The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:
        {code}
        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
        {code}
          
        After my restructuring it looks like this:
        {code}
        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
        {code}
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:
        {code}
        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
        {code}
          
        After my restructuring it looks like this:
        {code}
        Initial

        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
        {code}
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ate Douma made changes -
        Description The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to clearer separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:
        {code}
        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
        {code}
          
        After my restructuring it looks like this:
        {code}
        Initial

        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
        {code}
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        The current SCXML object model is still rather 'flat' and de-normalized, and many of the current SCXML specification features as well as restrictions are not fully mapped.

        I'll restructure the current model to bring it more/mostly in line with the specification and normalize the object hierarchy to cleaner separate and restrict the features belonging to the right level and element.

        The current state and transition model hierarchy is like this:
        {code}
        TransitionTarget
          <- Initial
          <- History
          <- State
               <- Final
          <- Parallel

        Executable
          <- Transition
        {code}
          
        After my restructuring it looks like this:
        {code}
        Initial

        TransitionTarget
          <- History
          <- EnterableState -> DocumentOrder
               <- TransitionalState
                    <- State
                    <- Parallel
               <- Final

        Executable
          <- SimpleTransition
               <- Transition -> DocumentOrder
        {code}
          
        With the above restructuring, each of these model objects now cleanly represents their functional role in the SCXML specification and only contains the features and relations they are supposed to have.

        I will also update the SCXML document parsing of the model and the validation and post-processing, and introduce some handy optimizations like adding a document order indicator to the EnterableState and Transition object which makes sorting them in document or reverse-document order, as needed for implementing the SCXML processing algorithm, very trivial and fast. And for each TransitionTarget its ancestor tree will be derived once and cached as a fast navigable array.

        All these changes have a big impact on the *internal* API because not everything is passed around as a TransitionTarget anymore but as strongly typed as possible. But these changes makes it much clearer to understand and use, and are an important improvement needed for implementing the full SCXML specification.
        Ate Douma made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Ate Douma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development