<commit_before><?xml version="1.0" encoding="UTF-8"?>
<!--
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
-->
<document>
  <properties>
    <title>Commons SCXML Roadmap</title>
    <author email="<EMAIL>">Commons Documentation Team</author>
  </properties>
  <body>
    <section name="Commons SCXML 2.0 Roadmap">
      <p>
        The last SCXML release 0.9 has been quite some time ago (2008) and since then the
        <a href="http://www.w3.org/TR/scxml/" target="_blank">W3C SCXML specification</a> has progressed and changed
        quite a lot, and almost ready to move to Candidate Recommendation status.
      </p>
      <p>
        The goal for Commons SCXML 2.0 is to get alignment (back) and be compliant with the W3C SCXML specification,
        but for this a lot of major changes are needed, both to the public API and, even more so, to the internal
        model and processing logic.
      </p>
      <p>
        To be able to make such major changes in an effective way, we already cleaned out a lot of the old but no
        longer relevant, working or otherwise incompatible features from the previous SCXML (0.9) version, see
        <a href="#Milestone_0:_Cleanup_(done)">Milestone 0</a> below.
      </p>
      <p>
        The work needed towards Commons SCXML 2.0 has been divided in a set of high-level targets and corresponding
        milestones:
      </p>
      <subsection name="Milestone 0: Cleanup (done)">
        <p>
          The first and already completed target was to cleanup and clean out no longer relevant or even no longer
          working features, or features which would make it very hard or complicated to keep working and supported
          for the major changes ahead.
        </p>
        <p>
          The support for the following features and integrations has been dropped: Shale/JSF, Rhino/E4X, Servlet/JSP.
        </p>
        <p>
          Note: some of the dropped features <em>might</em> be restored or re-implemented again once we reached a
          reasonable level of stability for the new APIs and internal logic, but that also will depend on the level of
          interest and support from the community.
        </p>
        <p>
          Technically, this milestone 0 still is largely compatible with the 0.9 release,
          just without those above mentioned features, and also now requires Java 6+. In addition this milestone also
          contains several fixes and enhancements (like Groovy language support).
        </p>
      </subsection>
      <subsection name="Milestone 1: Redesign semantics and processing components">
        <p>
          The target for milestone 1 is a redesign and better separation of concerns of the main SCXML processing
          components: SCXMLSemantics, SCXMLExecutor and SCInstance.
        </p>
        <p>
          The high-level plan is to:
          <ul>
            <li>Redefine SCXMLSemantics to align with the
              <a href="http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation" target="_blank">
                SCXML Algorithm for SCXML Interpretation</a>
              <p>
                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.
              </p>
              <p>
                Also, developers wishing to extend or customize the SCXMLSemantics will have a hard time to match that
                against the algorithm as well.
              </p>
              <p>
                The intend therefore is to start with a new SCXMLSemantics interface from scratch which (largely)
                follows the algorithm in the specification.
              </p>
            </li>
            <li>
              Better separation of concern between SCXMLExecutor and SCInstance.
              <p>
                The purpose of SCInstance is to be used as backing store for internal SCXML state. However
                over time some processing and transient state based features have ended up in SCInstance which are more
                appropriated to be managed by the SCXMLExecutor instead.
              </p>
              <p>
                Conversely, SCXMLExecutor maintains the current Status for the SCXML state as well as the internal
                events list going with it. Having the Status, without the processing related events list, to be
                managed by SCInstance instead would be better fitting.
              </p>
              <p>
                And finally, SCXMLExecutor currently doesn't yet provide a good abstraction or implementation of the
                <a href="http://www.w3.org/TR/scxml/#SCXMLEventProcessor" target="_blank">
                  SCXML Event I/O Processor</a> functionally.
                The internal and external event I/O management is a critical requirement and many features of the
                specification rely on it fulfilling this contract.<br/>
                The goal for this milestone is to provide a least a basic level of support for the SCXML Event I/O
                Processor and Event queue handling features.<br/>
              </p>
              <p>
                Overall, the intend is to let SCXMLExecutor be responsible as SCXML Processor and SCXML I/O Processor
                and to maintain all transient processing state including the system variables, while delegating to
                SCXMLSemantics for dealing with the processing algorithm.
              </p>
            </li>
          </ul>
        </p>
      </subsection>
      <subsection name="Milestone 2: Datamodel and data manipulation alignment">
        <p>The target for milestone 2 is to get better alignment with the SCXML datamodel specification.</p>
        <p>
          The Commons SCXML datamodel and context features are very flexible and can be defined and redefined in a
          hierarchical way (per state element). However this also makes it much more complex to manage, especially for
          XPath (XML) datamodel definitions.
        </p>
        <p>
          The SCXML specification however is very explicit in its requirements that, while datamodel elements may be
          defined in multiple locations within an SCXML document, together they must be accessible (and thus managed) as
          a single datamodel definition.
        </p>
        <p>
          The current Commons SCXML datamodel (and the backing Context handling) is to some extend actually more
          flexible and generic than what is possible <em>AND</em> allowed by the specification.
        </p>
        <p>
          To be able to be compliant with the specification, the <em>default</em> datamodel management in
          Commons SCXML will have to be more restricted and simplified.<br/>
          That will actually make things much easier to implement. For an XPath (XML) datamodel then only a single
          (aggregated) XML datamodel document can be used and the custom Commons SCXML Data() function no longer will be
          needed to access the data elements.
        </p>
        <p><commit_msg>Update roadmap for the now completed Milestone 1<commit_after><?xml version="1.0" encoding="UTF-8"?>
<!--
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
-->
<document>
  <properties>
    <title>Commons SCXML Roadmap</title>
    <author email="<EMAIL>">Commons Documentation Team</author>
  </properties>
  <body>
    <section name="Commons SCXML 2.0 Roadmap">
      <p>
        The last SCXML release 0.9 has been quite some time ago (2008) and since then the
        <a href="http://www.w3.org/TR/scxml/" target="_blank">W3C SCXML specification</a> has progressed and changed
        quite a lot, and almost ready to move to Candidate Recommendation status.
      </p>
      <p>
        The goal for Commons SCXML 2.0 is to get alignment (back) and be compliant with the W3C SCXML specification,
        but for this a lot of major changes are needed, both to the public API and, even more so, to the internal
        model and processing logic.
      </p>
      <p>
        To be able to make such major changes in an effective way, we already cleaned out a lot of the old but no
        longer relevant, working or otherwise incompatible features from the previous SCXML (0.9) version, see
        <a href="#Milestone_0:_Cleanup_(done)">Milestone 0</a> below.
      </p>
      <p>
        The work needed towards Commons SCXML 2.0 has been divided in a set of high-level targets and corresponding
        milestones:
      </p>
      <subsection name="Milestone 0: Cleanup (completed: 2014-03-11)">
        <p>
          The first and already completed target was to cleanup and clean out no longer relevant or even no longer
          working features, or features which would make it very hard or complicated to keep working and supported
          for the major changes ahead.
        </p>
        <p>
          The support for the following features and integrations has been dropped: Shale/JSF, Rhino/E4X, Servlet/JSP.
        </p>
        <p>
          Note: some of the dropped features <em>might</em> be restored or re-implemented again once we reached a
          reasonable level of stability for the new APIs and internal logic, but that also will depend on the level of
          interest and support from the community.
        </p>
        <p>
          Technically, this milestone 0 still is largely compatible with the 0.9 release,
          just without those above mentioned features, and also now requires Java 6+. In addition this milestone also
          contains several fixes and enhancements (like Groovy language support).
        </p>
      </subsection>
      <subsection name="Milestone 1: Redesign semantics and processing components (completed: 2014-04-03)">
        <p>
          The target for milestone 1 is a redesign and better separation of concerns of the main SCXML processing
          components: SCXMLSemantics, SCXMLExecutor and SCInstance.
        </p>
        <p>
          The high-level plan is to:
          <ul>
            <li>Redefine SCXMLSemantics to align with the
              <a href="http://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation" target="_blank">
                SCXML Algorithm for SCXML Interpretation</a>
              <p>
                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.
              </p>
              <p>
                Also, developers wishing to extend or customize the SCXMLSemantics will have a hard time to match that
                against the algorithm as well.
              </p>
              <p>
                The intend therefore is to start with a new SCXMLSemantics interface from scratch which (largely)
                follows the algorithm in the specification.
              </p>
            </li>
            <li>
              Better separation of concern between SCXMLExecutor and SCInstance.
              <p>
                The purpose of SCInstance is to be used as backing store for internal SCXML state. However
                over time some processing and transient state based features have ended up in SCInstance which are more
                appropriated to be managed by the SCXMLExecutor instead.
              </p>
              <p>
                Conversely, SCXMLExecutor maintains the current Status for the SCXML state as well as the internal
                events list going with it. Having the Status, without the processing related events list, to be
                managed by SCInstance instead would be better fitting.
              </p>
              <p>
                And finally, SCXMLExecutor currently doesn't yet provide a good abstraction or implementation of the
                <a href="http://www.w3.org/TR/scxml/#SCXMLEventProcessor" target="_blank">
                  SCXML Event I/O Processor</a> functionally.
                The internal and external event I/O management is a critical requirement and many features of the
                specification rely on it fulfilling this contract.<br/>
                The goal for this milestone is to provide a least a basic level of support for the SCXML Event I/O
                Processor and Event queue handling features.<br/>
              </p>
              <p>
                Overall, the intend is to let SCXMLExecutor be responsible as SCXML Processor and SCXML I/O Processor
                and to maintain all transient processing state including the system variables, while delegating to
                SCXMLSemantics for dealing with the processing algorithm.
              </p>
            </li>
          </ul>
        </p>
        <p>
          This milestone has now been completed and the most prominent changes and new features can be reviewed
          through JIRA issues <a href="https://issues.apache.org/jira/browse/SCXML-196" target="_blank">SCXML-196</a>,
          <a href="https://issues.apache.org/jira/browse/SCXML-197" target="_blank">SCXML-197</a> as well as
          <a href="https://issues.apache.org/jira/browse/SCXML-200" target="_blank">SCXML-200</a>.
        </p>
      </subsection>
      <subsection name="Milestone 2: Datamodel and data manipulation alignment">
        <p>The target for milestone 2 is to get better alignment with the SCXML datamodel specification.</p>
        <p>
          The Commons SCXML datamodel and context features are very flexible and can be defined and redefined in a
          hierarchical way (per state element). However this also makes it much more complex to manage, especially for
          XPath (XML) datamodel definitions.
        </p>
        <p>
          The SCXML specification however is very explicit in its requirements that, while datamodel elements may be
          defined in multiple locations within an SCXML document, together they must be accessible (and thus managed) as
          a single datamodel definition.
        </p>
        <p>
          The current Commons SCXML datamodel (and the backing Context handling) is to some extend actually more
          flexible and generic than what is possible <em>AND</em> allowed by the specification.
        </p>
        <p>
          To be able to be compliant with the specification, the <em>default</em> datamodel management in
          Commons SCXML will have to be more restricted and simplified.<br/>
          That will actually make things much easier to implement. For an XPath (XML) datamodel then only a single
          (aggregated) XML datamodel document can be used and the custom Commons SCXML Data() function no longer will be
          needed to access the data elements.
        </p>
        <p>
{'fraction_non_alphanumeric': 0.05897373540856031, 'fraction_numerical': 0.006748540856031129, 'mean_word_length': 2.287827303617829, 'pattern_counts': {'":': 0, '<': 181, '<?xml version=': 2, '>': 181, 'https://': 3, 'lorem ipsum': 0, 'www.': 8, 'xml': 8}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '782704', 'n_tokens_mistral': 4072, 'n_tokens_neox': 3849, 'n_words': 1991}