[jira] [Resolved] (SCXML-218) Uniqueness of IDs

["Ate Douma (JIRA)" <ji...@apache.org>]

     [ 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)