[
https://issues.apache.org/jira/browse/SCXML-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved SCXML-242.
-----------------------------
Resolution: Fixed
Thanks [~woon_san] for the review!
Concerning the suggested improvements for the ContentParser: they all make
sense.
However, I'm actually working on rewriting the SCXMLReader completely, making
it XML DOM instead of XMLStream based...
There are just too many use-cases (not yet, or not properly, implemented) which
need an XML DOM representation or parsing of the SCXML model, like for an
<invoke> with an nested <content> containing an embedded SCXML document, or
other <content> use-cases.
The current SCXMLReader currently cannot be used for this but first need a
stringified representation again to be able to parse it (again!) via XMLStream.
Making this XML DOM based 'parsing' really simplifies things a lot further, and
this will also 'affect' (simplify) the logic currently contained within the
ContentParser.
Maybe even no longer needed (to be merged back into the new SCXMLReader).
Anyway, I will take you suggestions into account for this rewrite.
Concerning the earlier suggestion about using Node.getTextContent() in
#readData() instead of using #getNodeValue():
this isn't needed and won't make a difference as the content parsing in
#readNode already deals with CDATA content (converting it into a single
TEXT_NODE).
> Provide JSON based datamodel as replacement for XML/XPath
> ---------------------------------------------------------
>
> Key: SCXML-242
> URL: https://issues.apache.org/jira/browse/SCXML-242
> Project: Commons SCXML
> Issue Type: New Feature
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0
>
>
> The XML/XPath datamodel, with 'convenient' support through Data() and
> Location() operations for usage within the Jexl, Javascript and Groovy SCXML
> languages has been the root and cause of many invasive and complicating
> problems in the implementation of Commons SCXML (2.0).
> The [SCXML 1.0 specification|http://www.w3.org/TR/2015/REC-scxml-20150901/]
> has dropped the xpath datamodel from the specification because of
> similar/same complications and (also thereof) lack of 'reference'
> implementations.
> Further maintaining and trying to 'improve' on the XML/XPath datamodel
> support in Commons SCXML therefore will be stopped and removed from the
> implementation all together.
> Instead and as replacement new JSON datamodel support will be added, which
> also aligns with the (optional) Ecmascript datamodel as described in the
> SCXML specification.
> The JSON based datamodel will be parsed (in Java) into a 'raw' object model,
> consisting of plain Maps (JSON Object) and Lists (JSON Array), and thus
> trivially to be used from the Commons SCXML supported languages (Jexl, Groovy
> and Javascript).
> As this new JSON datamodel will replace all XML/XPath usages, part of this
> new feature implementation will be updating and replacing all the
> example/unit-test usages in the codebase, and thereby also removing all
> usages of the custom Data() and Location() functions.
> Once these changes are in place, the Data() and Location() custom functions
> will then be removed as well.
> Finally, the XPath language itself then can be removed, including all the
> supporting logic scattered throughout the engine implementation itself, but
> this will be done as a separate issue afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
