RE: The In() predicate

Stefan,
  The problem of ID conflicts is fairly high on the list of issues we would like to address in the next draft, and comments like yours to the public list will cause us to boost its priority. 

The current requirement that IDs be unique when the same source is included multiple times is simply a stop-gap solution so that documents can be validated against the schema, but, as you point out, authors need to be able to figure out what those unique IDs will be.

The use of fully qualified names is one of the options we will consider when we address this issue, but at this point we really don't know what our solution will be.  We also don't know when the next draft will be published, so in the interim implementations must either ignore the feature or find some sort of work around. 

- Jim

-----Original Message-----
From: www-voice-request@w3.org [mailto:www-voice-request@w3.org] On Behalf Of Stefan Maton
Sent: Tuesday, May 27, 2008 8:52 AM
To: www-voice@w3.org
Subject: The In() predicate


Hi,

I was taking a look at the In() predicate today because it's not been
implemented into SSCML yet. I didn't implement it yet since the old draft
(2007) didn't describe it very well.

Unfortunately, the new draft omits examples of this function. The examples
that I have found on the web which use In() (or the older In ) rise a
problem that might be encountered within a state machine which includes
multiple times the same source into a state machine.

Consider this state machine (please don't look at the "sense" or the old
semantics of this, it's just to give an example):

TLBase.xml:
<?xml version="1.0"?>
<scxml initialstate="Red">
  <state id="Green">
    <onentry>
      <send target="Self" event="goYellow" delay="5s"/>
    </onentry>
    <transition event="goYellow" target="Yellow"/>
  </state>
  <state id="Yellow">
    <onentry>
      <send target="Self" event="goRed" delay="3s"/>
    </onentry>
    <transition event="goRed" target="Red"/>
  </state>
  <state id="Red">
    <transition event="goGreen" target="Green"/>
  </state>
</scxml>

TrafficLight.xml:
<?xml version="1.0"?>
<scxml initialstate="TrafficLight1">
  <parallel id="TrafficLight1">
    <state id="TL1" src="TLBase.xml">
      <initial id="init">
        <transition target="Green"/>
      </initial>
      <transition cond="In(Red) && In(Red)" target="TrafficLight2"/>
    </state>
    <state id="TL2" src="TLBase.xml">
      <initial id="init">
        <transition target="Green"/>
      </initial>    </state>
  </parallel>
  <parallel id="TrafficLight2">
    <state id="TL3" src="TLBase.xml">
      <transition cond="In(Red) && In(Red)" target="TrafficLight1"/>
    </state>
    <state id="TL4" src="TLBase.xml">
    </state>
  </parallel>
</scxml>

As you can see, the In()-predicate, as I have encountered it in some web
examples, would not work in the above state machine.

So, my understanding is that the In()-predicate should take either the
complete "path" to the state or a "path" relative to a parent State.

Thus these two In() predicate usages would be right:

1. <transition cond="In(TrafficLight1.TL1.Red) && In(TrafficLight1.TL2.Red)"
target="TrafficLight2"/>
2. <transition cond="In(TL1.Red) && In(TL2.Red)" target="TrafficLight2"/>

I know that the draft states that the IDs must be unique within the
document. But I suppose that you can see the problem that this statement
creates: You would not be able to include multiple times the same source
within your document (the above mentioned traffic light example is a valid
example of why it should work). Altering the name of the "substate" while
loading would not work since you could not address the state in a rightful
manner anymore. Therefore I think it's not the state ID that should be
unique but the "path" to the state.

Perhaps there's another way to realize what I wrote above? Using the In()
without altering the definition of an id?

Thanks,
Stefan
---------------------------------------------------
Sidéma
Rue Lefin 4, 4860 Pepinster, Belgique
Web: http://www.sidema.be
Email: maton@sidema.be
GSM: ++32 (0)494 / 11.53.65
TVA BE 0713.367.395

Received on Tuesday, 27 May 2008 13:30:18 UTC