Scxml -> SVG render disregards label

[LeeDoty]

Expected Behavior

Be able to render aliases (i.e. labels) for nested states. As smcat requires all state names to be unique, and our system uses reusable sub-states, I need to be able to specify full paths to those sub states.

Example:

outer {
    inner.one [label="one"] {
        inner.one.innerest [label="innerest"];
    },
    inner.two [label="two"] {
        inner.two.innerest [label="innerest"];
    };
};

This renders wonderfully using smcat, however I can't seem to get the magic right to do the same in scxml.

Using smcat to render the above smcat to scxml gives me:

<?xml version="1.0" encoding="UTF-8"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
    <state id="outer">
        <state id="inner.one">
            <state id="inner.one.innerest">
            </state>
        </state>
        <state id="inner.two">
            <state id="inner.two.innerest">
            </state>
        </state>
    </state>
</scxml>

which strips off the labels. This is a problem, but not my use case.

Current Behavior

1. rendering from smcat -> scxml strips off the label information
2. if I then add labels to the scxml, they aren't rendered in SVG

Possible Solution

What I need is the ability to specify the labels in some way and have it render as SVG. (having smcat render the smcat -> scxml would be nice too)

Like maybe:

<?xml version="1.0" encoding="UTF-8"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0">
    <state id="outer" label="outer">
        <state id="inner.one"  label="one">
            <state id="inner.one.innerest"  label="innerest">
            </state>
        </state>
        <state id="inner.two"  label="two">
            <state id="inner.two.innerest" label="innerest">
            </state>
        </state>
    </state>
</scxml>

Steps to Reproduce (for bugs)

render the smcat/scxml given above

Context

Right now, I'm fine. I can just use smcat format to generate SVGs. However, I did have to add a generator for smcat format from our internal code. No biggie, I prefer smcat. However, in the future we might need to generate scxml (say to integrate with an editor) and we'd not be able to use that scxml to render in smcat.

Your Environment

validated in current atom plugin and https://state-machine-cat.js.org/

[sverweij]

SCXML doesn't have labels for states as a concept (see the state section of the spec), so I'm afraid you're out of luck if you want to use that feature with SCXML.

smcat -> scxml should yield valid SCXML, so the labels have nowhere to go...

If you're ever be in the need of a machine readable/ writeable format could smcat's object model be an alternative (ruled by a json schema)?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.