[
https://issues.apache.org/jira/browse/SCXML-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved SCXML-218.
-----------------------------
Resolution: Not a Problem
Hi Johannes,
First of all, JIRA issues are not intended for such open questions or
discussions.
In the future please raise such questions on the users@ or dev@ lists instead.
And, I'm closing this as "Not a Problem" because your 'issue' really isn't
something which we can 'fix'.
A SCXML state ID is and has to be a unique identifier across the SCXML *XML*
document, because so much of the SCXML functionality is depending on it. like
for example to uniquely identify <transition> targets. These need to be able to
address a specific state, and replacing this by some kind of hierarchical
element path identifier really won't solve your problem either: it will just
make it more difficult and only 'shift' the problem elsewhere.
But even more fundamentally, an SCXML document is an XML document, and and XML
element ID strictly is and must be unique. A proper XML parser won't only just
complain when it encounters duplicate id's: it will simply *fail* to parse the
document.
If you would want to 'fix' this, you would have to 'fix' the XML specification
itself first, and/or raise your problem at the SCXML specification group to use
other means to identify states.
But to be honest: I give you zero chance with that.
At any rate: this is definitely not something we at the Apache Commons SCXML
project can (or even want to) do anything about.
All that said: using Commons SCXML you can use SCXML *without* backing XML
document if you really want to.
Just by using the Java API you can dynamically create SCXML state machine
definitions, and if you really need to wire it together using 'templates' you
also could dynamically generate your own hierarchically derived unique state
IDs.
p.s. I noticed in your example you even have *multiple* id attributes on a
single element. For what purpose isn't clear to me, but that definitely won't
parse either...
> Uniqueness of <state> IDs
> -------------------------
>
> Key: SCXML-218
> URL: https://issues.apache.org/jira/browse/SCXML-218
> Project: Commons SCXML
> Issue Type: Improvement
> Affects Versions: 2.0
> Reporter: Johannes Neuber
>
> h1. Uniqueness of IDs across a whole SCXML specification/document
> Why have the state IDs to be unique across a whole SCXML
> specification/document? This is a big disadvantage, especially if you want to
> use compound states/hierarchical states and if you have recurring state
> structures ("state templates"). In real projects you will have to structure
> thousands or tens of thousands states.
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml"; version="1.0"
> xmlns:cs="http://commons.apache.org/scxml"; initial="mainMenu">
> <state id="mainMenu" id="main.idle">
> <state id=" main.idle"/>
> <transition event="navi" target="naviSubMenu" />
> <transition event="phone" target="phoneSubMenu" />
> <transition event="help" target="help" />
> <state id="naviSubMenu" id="navi.idle">
> <state id=" navi.idle"/>
> <transition event="help" target="help" />
> <!- ... -->
> <state id="help"/>
> </state>
>
> <state id="phoneSubMenu" id="phone.idle">
> <state id=" phone.idle"/>
> <transition event="help" target="help" />
> <!--... -->
> <state id="help"/>
> </state>
> <state id="help">
> <!-- ... -->
> </state>
> </state>
>
> <final id="end"/>
> </scxml>
> {code}
> The example is really simple, but shows the problem impressively. The SCXML
> parser will complain, that the state with *id="help"* is used more than once.
> But where is the problem? The states are unique! Not in the context of the
> whole document, but *in their "path" of the (sub)tree they are unique*. You
> could easily imagine to address them in a "package notation" manner (like in
> every Object Oriented Programming language):
> 1. mainMenu/help (mainMenu.help)
> 2. mainMenu/naviSubMenu/help (mainMenu.naviSubMenu.help)
> 3. mainMenu/phoneSubMenu/help (mainMenu.phoneSubMenu.help)
> h1. State Templating:
> Because of the above constraint a "state templating" in the following manner
> wouldn't be possible too:
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml"; version="1.0"
> xmlns:cs="http://commons.apache.org/scxml"; initial="mainMenu">
> <state id="mainMenu" src="stateTemplate.xml" id="main.idle">
> <state id=" main.idle"/>
> <transition event="navi" target="naviSubMenu" />
> <transition event="phone" target="phoneSubMenu" />
> <state id="naviSubMenu" src="stateTemplate.xml" id="navi.idle">
> <state id=" navi.idle"/>
> <!-- ... -->
> </state>
>
> <state id="phoneSubMenu" src="stateTemplate.xml"
> id="phone.idle">
> <state id=" phone.idle"/>
> <!-- ... -->
> </state>
> <final id="end"/>
> </scxml>
> {code}
> *stateTemplate.xml:*
> {code:xml}
> <scxml xmlns="http://www.w3.org/2005/07/scxml"; version="1.0"
> xmlns:cs="http://commons.apache.org/scxml";>
> <transition event="help" target="help" />
> <state id="help">
> <!-- ... -->
> </state>
> </scxml>
> {code}
> The constraint for unique state IDs across a whole SCXML specifications/
> document makes a big SCXML specification almost un-manageable and the usage
> of state templates impossible. Therefor in my opinion the current SCXML2
> implementation isn't suitable for "real-life" projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
