Ignore

Ignoring an event

An event listed in a state's ignore section is accepted in that state and deliberately discarded. No transition, no activity, no error.

Here is the Door's OPENING state:

state OPENING
activity
transitions
    Door opened > OPEN
    Passenger close > CLOSING
ignore
    Passenger open
        The passenger can hit the open button all they like at this point,
        but it will be ignored since the door is, in fact, opening now.
    Lock
        <Lock checked later> There’s nothing to do at this point, but we assume the lock attribute
        will be set and we will check it later, so the event info is not lost.

It makes sense that a passenger pressing the open button is ignored — the door is already opening, so there is nothing to do and nothing has gone wrong.

The grammar:

ignores = ignore_header response*
ignore_header = "ignore" EOL*
response = INDENT event_name (SP tag)? EOL* explanation?

An unindented ignore keyword opens the section, each event name follows on its own indented line, and its explanation is indented one level further — or, where the explanation is only a reference to a reason defined elsewhere, on the event line itself. See Reason tags. The section has no -- of its own; the unindented -- that closes the state block closes this too. See State block grammar.

The ignore section is optional, and so is the explanation under any given event — though writing one is the whole point. See Reason tags for the <angle bracket> labels that let one reason be shared across several states.

An ignore is proper behavior, not an error

Worth stating plainly, because the other non-transition response, can't happen, looks superficially similar and means something completely different. An ignore says this event legitimately arrives here and the correct response is to do nothing. A can't happen says this event cannot legitimately arrive here at all.

If a running system delivers an ignored event, everything is fine. If it delivers a can't-happen event, something has gone wrong that the model does not describe.

The older bare-event form

Before the ignore section existed, an ignore was written inside transitions as an event name with no > and no destination:

transitions
    Door opened > OPEN
    Passenger close > CLOSING
    Passenger open
    Lock

The optional destination in transition = INDENT event_name (SP '>' SP state_name)? EOL* still permits this, so older files continue to parse. Prefer the ignore section in anything new: the bare form leaves the reason nowhere to live, which is exactly what let the ignore and can't-happen decisions drift out of the xsm files in the first place.

What the parser gives you

An ignores list on StateBlock_a, holding one Response_a per event with event, tag and explanation fields. An ignore written in the older bare form arrives instead as a Transition_a in transitions with to_state set to None.