Nabble - w3.org - www-voice

Re: Comments on CCXML specification - [cc] ISSUE-637

2009-12-08T20:32:55Z

Petr:

This change has been accepted and applied to the internal copy of the spec.

Best regards,

RJ
---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

On Oct 22, 2009, at 5:49 AM, RJ Auburn wrote:

> Petr:
>
>
>>> 3) Attribute 'info' in the conference.created and conference.destroyed events - ISSUE-637
>>>
>>> Our idea to work around the problem (2) was to use the platform dependent attribute 'info' in the conference.created event. However, in contrast to the connection.* events there is no such attribute in conference.created nor conference.destroyed events. Is there any reason for this?
>>>
>>> Our suggestion is to add attribute 'info' to the conference.created and conference.destroyed events with the same meaning this attribute has in connection.* events.
>
> This looks like an oversight in the specification. We will discuss this on the next CCXML working group call and see if we can fix it in the candidate recommendation.
>
> Best regards,
>
> RJ
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> Chair, Editor and Chair, CCXML, VBWG, W3C
>
>
>

Re: CCXML: using Object in the application scope - example error - ISSUE-633

2009-12-08T20:23:11Z

Peter,

This change has been accepted and applied to the internal copy of the spec.

Best regards,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Oct 22, 2009, at 5:23 AM, RJ Auburn wrote:

> Petr,
>
> This is tracked as ISSUE-633.
>
> Thanks,
>
> RJ
>
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
>
> On Sep 30, 2009, at 3:01 PM, Petr Kuba wrote:
>
>> Hello,
>>
>> We believe that there is an error in the CCXML specification, section 8.4.
>>
>> The example in this section shows how to create an Object in the application scope:
>>
>> <var name="application.obj" expr="new Object()"/>
>>
>> We assume that behavior of the <var> tag should be the same as behaviour of a var statement within a <script> (although it is not explicitly stated in the specification). However, the following statement is not allowed in ECMAScript:
>>
>> var application.obj = new Object();
>>
>> However, it is correct to use the the following statement in ECMAScript:
>>
>> application.obj = new Object();
>>
>> Therefore we believe that correct version of the CCXML example is:
>>
>> <assign name="application.obj" expr="new Object()"/>
>>
>> In this case, the description above the example should be clarified as well.
>>
>> Thanks for response,
>>
>> Petr Kuba
>>
>>
>> --
>> Petr Kuba, Project Manager
>> OptimSys, s.r.o
>> kuba@...
>> Tel: +420 541 143 065
>> Fax: +420 541 143 066
>> http://www.optimsys.cz
>>
>
>

[voicexml30] fouth WD of VoiceXML 3.0 has been published

2009-12-07T05:56:51Z

Hi www-voice,

As announced on the W3C top page
(http://www.w3.org/News/2009#entry-8667), the fourth Working Draft of
VoiceXML 3.0 has been published as follows.

This version:
http://www.w3.org/TR/2009/WD-voicexml30-20091203/

Latest version:
http://www.w3.org/TR/voicexml30/

Previous version:
http://www.w3.org/TR/2009/WD-voicexml30-20090825/

A diff-marked version is also available for comparison purposes at:
http://www.w3.org/TR/voicexml30/diff.html

The main difference from the previous draft is addition of run time
control and SIV modules.

Comments are welcomed to this Voice public list, <www-voice@...>.

Best regards,

Kazuyuki Ashimura
for the W3C Voice Browser WG

--
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@...
voice: +81.466.49.1170 / fax: +81.466.49.1171

Re: [scxml] sixth WD of SCXML is published

2009-11-19T20:41:16Z

Jim Barnett wrote:

>
>
> Greg,
>
> Here are responses to two more of your requests. We will respond to the
> rest as we review them.
>
>
>
> 2. Would it be possible for transition/@event to be of type NMTOKENS
> instead of NMTOKEN?
>
> >> We have accepted this request. In the next public working draft, it
> will be possible to specify multiple event names in transition/@event
> (though we haven’t decided exactly what type to use in the schema.)

Excellent; thank you.

> What happens if a <history> with no default transition is the target
>
> of a transition?
>
> >> This cannot happen because the transition is mandatory. Section
> 3.11.2 says that the transition child “Occurs once.” However, the
> schema needs to be fixed since it makes the transition child optional.
> This will be fixed in the next draft.

OK, that clears some things up. Are you making it explicitly mandatory,
or "mandatory with an implicit default" such as was done with
initial|@initial in this recent WD?

Thanks for your reply.

-- Greg

Re: [scxml] sixth WD of SCXML is published

2009-11-19T11:42:22Z

Greg,

Here are responses to two more of your requests. We will respond to the rest as we review them.

2. Would it be possible for transition/@event to be of type NMTOKENS instead of NMTOKEN?

>> We have accepted this request. In the next public working draft, it will be possible to specify multiple event names in transition/@event (though we haven’t decided exactly what type to use in the schema.)

What happens if a <history> with no default transition is the target

of a transition?

>> This cannot happen because the transition is mandatory. Section 3.11.2 says that the transition child “Occurs once.” However, the schema needs to be fixed since it makes the transition child optional. This will be fixed in the next draft.

- Jim

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Re: [scxml] sixth WD of SCXML is published

2009-11-12T15:12:18Z

Jim Barnett wrote:
> Greg,
> On your specific point below, the global uniqueness of IDs regardless
> of type is part of XMLSchema.

Right, I get that; that's why I was wondering about its use in SCXML (as
opposed to multiple xsd:keys).

> I don't know what that group's motivation
> was, though I imagine it makes document validation simpler. In any

I would guess it's mainly for compatibility with DTDs.

> case, given that that's the way XMLSchema works, it's easiest for us to
> adopt their definition.

OK. My main reason for asking was that for implementations with a
non-validating XML parser, it's an extra enforcement step for keyspaces
that I would assume are otherwise naturally separate. (Or at least it is
if you're going for strict SCXML conformance.)

-- Greg

RE: [scxml] sixth WD of SCXML is published

2009-11-12T08:48:01Z

Greg,
On your specific point below, the global uniqueness of IDs regardless
of type is part of XMLSchema. I don't know what that group's motivation
was, though I imagine it makes document validation simpler. In any
case, given that that's the way XMLSchema works, it's easiest for us to
adopt their definition.

- Jim

"Is there any
context in which uniqueness of IDs over types of objects that are
effectively disjoint (such as states vs. data model fields) is
important, or is this mainly just for general readability and ambiguity
prevention?" (If you had something like "typeof('abc')=='state'" and
"typeof('def')=='datafield'", for example, then this would be a clear
situation where two different types of object should not be able to have

the same ID).

Or is it just that it's simpler for a parser to validate a document
using ID/IDREF than one with a bunch of different schema keys?

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Re: [scxml] sixth WD of SCXML is published

2009-11-11T17:25:41Z

Jim Barnett wrote:
> Greg,
> We will reply to the rest of your comments as we have time to review
> them. Here are responses to a few of them:

Yes, sorry about that. I admit it was a bit of a brain dump. No rush.

> 5. Section 9 on IDs does not specify the scope of uniqueness
>>> The section states: "The values of all attributes of type "id" MUST
> be unique within the session."

Sorry, yes; my mistake. I guess what I really meant was "Is there any
context in which uniqueness of IDs over types of objects that are
effectively disjoint (such as states vs. data model fields) is
important, or is this mainly just for general readability and ambiguity
prevention?" (If you had something like "typeof('abc')=='state'" and
"typeof('def')=='datafield'", for example, then this would be a clear
situation where two different types of object should not be able to have
the same ID).

Or is it just that it's simpler for a parser to validate a document
using ID/IDREF than one with a bunch of different schema keys?

> 7. The algorithm seems to potentially run into infinite recursion on
> default history state transitions if multiple default history state
> transition targets create a circuit
>>> We will look at this more closely, but in general SCXML and all
> other state machine languages are so rich in possibilities for infinite
> loops that we can never hope to eliminate all of them.

Of course. This one in particular just seemed to be something that was
easily detectable or preventable with a rule change.

>>> yes, the intent was 'descendant', so we would like to hear about the
> issues with <initial> and <parallel>

OK. First off is just a little inconsistency between section 3.5.2 and
the sections which describe @initial (3.1.1 and 3.2.1). Section 3.5.2
says "must be a descendant", but with @initial being of type IDREFS, I'm
guessing this should be "must be one or more descendants" (or however
you want to word it to work in a mention of <parallel> -- maybe even
just copying the text from the descriptions of @initial).

Now, more importantly: <parallel> does not currently allow <initial>,
but given the definition of <initial>, it seems like it could
potentially serve a valid purpose.

The first such reason would be executable content. You might say that
parallel/onentry could already handle this, but remember that <onentry>
cannot be skipped by transitions, whereas transitions that directly
target child states will skip the initial/transition executable content
of those states' ancestors.

The second reason is a little more involved, but it's along those same
lines. As you've confirmed for me, initial transition targets must be
descendants of the <initial> parent's element -- not necessarily direct
children:

<state name="S1" initial="S3">
<state name="S2">
<initial>
<transition target="S3">
<log expr="'Passed through S2'" />
</transition>
</initial>

<state name="S3" />
</state>
</state>

In other words, in the case above, entering S1 directly would mean
entering S3 directly, skipping over S2's initial transition (i.e. S2 is
not added to statesForDefaultEntry in the algorithm), and the <log>
would not be executed.

Now, presumably (and please correct me if I'm wrong on this) <parallel>
does not allow <initial> because when a parallel state is entered, all
of its children are entered as well. But this means all children trigger
their initial transition (because they're all added to
statesForDefaultEntry). True, there is no difference in functionality if
you were to have an @initial that specified only direct child states,
but as above, specifying one or more states at the grandchild level or
deeper WOULD have an effect:

<parallel state="P1" initial="S3">
<state name="S1" />
<state name="S2">
<initial>
<transition target="S3">
<log expr="'Passed through S2'" />
</transition>
</initial>

<state name="S3" />
</state>
</parallel>

In this case above, upon entering P1, S1 and S3 would be entered, and
again S2's initial transition would be skipped over. (This also means
initial="S3" is the same as initial="S1 S3", and not specifying an
initial transition is the same as "S1 S2").

Of course, the same effect could be achieved by wrapping the <parallel>
in a <state initial="S3">, but this seems like an unnecessary extra
step. It also means that if you're making use of parallel/state/final,
the "done.state.*" event does not have the same ID as the wrapper <state>.

> 4. What are the semantics of the in() predicate in any of the
> intermediate places where executable content is used? What I mean by
> this is that just about everywhere that executable content is used
> except for transition/@cond, the current state configuration is in the
> middle of being modified (onentry, onexit, (state |
> parallel)/transition, initial/transition).
> If the answer here is "add/remove states in the configuration when the
> algorithm says so," then OK. I just wanted to make sure, since 8.1,
> 10.2.5.1, and 10.3.4.1 don't say anything about this.
>
>>> Yes, the intent is to add/remove states following the algorithm.

OK. With that in mind, would you see any benefit to pre- and
post-microstep versions of in()? That is, during <transition>,
<onentry>, or <onexit>, the former would enable access to the state
configuration from before the microstep began, and the latter would
enable access to what the state configuration will be when the microstep
completes. I say that for reasons of parallel states such as the following:

<parallel>
<state id="SA">
<state id="SA1">
<transition event="move" target="SA2" />
</state>
<state id="SA2" />
</state>
<state id="SB">
<state id="SB1">
<onexit>
<if cond="in('SA1')"><log expr="'In SA1'"/></if>
<if cond="in('SA2')"><log expr="'In SB1'"/></if>
<if cond="in('SB1')"><log expr="'In SB1'"/></if>
<if cond="in('SB2')"><log expr="'In SB2'"/></if>
<if cond="in('SC1')"><log expr="'In SC1'"/></if>
<if cond="in('SC2')"><log expr="'In SC2'"/></if>
</onexit>
<transition event="move" target="SB2" />
</state>
<state id="SB2" />
</state>
<state id="SC">
<state id="SC1">
<transition event="move" target="SC2" />
</state>
<state id="SC2" />
</state>
</parallel>

Assuming a configuration containing "SA1 SB1 SC1", the "move" event will
trigger all three transitions. However, in SB1's <onexit>, we get the
log entries "In SB1" and "In SC1" -- SA1 has already been exited,
leaving no trace that we used to be there, whereas SC1 gives no
indication that it is also about to be exited. This means In() has a
dependency on document order that I believe could be eliminated.

> 9. Are there any plans for state machine instance serialization? i.e. I
> want to take a running instance, save its configuration, history states,
>
> event queue, etc. to a byte array, and then restore it at a later time
>
>>> We have discussed this and think it's out of scope, at least for the
> first version of the spec. We expect that most implementations will
> support something like this, and are interested in suggestions for
> things that we could add to the spec to make serialization easier, but
> we don't see the need for a standard serialization format at the moment.

I figured as much. No complaints here; an extension is just fine. I am
interested myself in what other implementations have done with this (if
anything).

> = Jim Barnett

Thanks for your reply.

-- Greg

RE: [scxml] sixth WD of SCXML is published

2009-11-11T07:20:53Z

Greg,
We will reply to the rest of your comments as we have time to review
them. Here are responses to a few of them:

5. Section 9 on IDs does not specify the scope of uniqueness
>> The section states: "The values of all attributes of type "id" MUST
be unique within the session."

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit
>> We will look at this more closely, but in general SCXML and all
other state machine languages are so rich in possibilities for infinite
loops that we can never hope to eliminate all of them.

And from your email of Nov 11

1. In section 3.5.2, where it says "the 'target' of the transition must
be a descendant of the <initial> element's parent <state>", was it
actually intended to say "descendant" and not "child" here? I ask
because if it is actually supposed to be "descendant", then there are
some issues that may need to be addressed regarding <initial> and
<parallel>. I can elaborate, but I want to make sure this is the case
first.

>> yes, the intent was 'descendant', so we would like to hear about the
issues with <initial> and <parallel>

4. What are the semantics of the in() predicate in any of the
intermediate places where executable content is used? What I mean by
this is that just about everywhere that executable content is used
except for transition/@cond, the current state configuration is in the
middle of being modified (onentry, onexit, (state |
parallel)/transition, initial/transition).
If the answer here is "add/remove states in the configuration when the
algorithm says so," then OK. I just wanted to make sure, since 8.1,
10.2.5.1, and 10.3.4.1 don't say anything about this.

>> Yes, the intent is to add/remove states following the algorithm.

9. Are there any plans for state machine instance serialization? i.e. I
want to take a running instance, save its configuration, history states,

event queue, etc. to a byte array, and then restore it at a later time

>> We have discussed this and think it's out of scope, at least for the
first version of the spec. We expect that most implementations will
support something like this, and are interested in suggestions for
things that we could add to the spec to make serialization easier, but
we don't see the need for a standard serialization format at the moment.

= Jim Barnett

-----Original Message-----
From: www-voice-request@... [mailto:www-voice-request@...] On
Behalf Of Greg Beauchesne
Sent: Sunday, November 01, 2009 10:02 PM
To: VoiceBrowser
Subject: Re: [scxml] sixth WD of SCXML is published

Kazuyuki Ashimura wrote:
> Hi www-voice,
>
> The sixth Working Draft of "State Chart XML (SCXML): State Machine
> Notation for Control Abstraction" has been published as follows.

Hello. My name is Greg Beauchesne. I guess I'm new here, but I've been
working on an SCXML implementation of my own and I figured that means I
should probably get in on this list.

So, without further ado...

1. I'm glad that the whole event name prefix issue has been updated to
use tokens. This had been causing me issues with event names like "up"
vs. "update".

2. Would it be possible for transition/@event to be of type NMTOKENS
instead of NMTOKEN? As it stands, if I want to have the same transition
be taken for two completely different events, with all of the associated

executable content, I have to copy and paste the entire transition
definition or otherwise use scripted functions to achieve common
functionality. I think this would not break anything, since NMTOKEN
already forbids whitespace. (Although technically I guess it's not
NMTOKEN anyway, according to the schema in D.1)

3. I also like the new expr vs. non-expr attributes; this really
clarifies when a string or expression should be used. On <send> and
<invoke>, I would say that @id and @idlocation is inconsistent with the
rest (@idexpr instead of @idlocation would probably match better), but
I realize this is probably for compatibility with previous WDs, not to
mention that it is the one attribute that acts as an lvalue.

4. Along the lines of the expr/non-expr attributes, I would see
value in something similar for <log>. It seems to me that @label is not
intended to be replacement for @expr (i.e. <log label="test"/> is not
necessarily the same as <log expr="'test'"/>, especially since @expr is
required and @label is not). So maybe something like <log message="My
message"/>?

If that were the case, though, it would probably get confusing as to
whether to use @label or @message. What was the intent behind the @label

attribute?

Alternatively or in addition, I think <log> could support child content
(at least text nodes) as an alternative to either the @label or @expr
attributes. <assign> and <data> already do this. For example, this:

<log>A thing happened</log>

....would be the same as this (assuming a compatible scripting
language):

<log expr="'A thing happened'"/>

5. Section 9 on IDs does not specify the scope of uniqueness. I know
that the XML ID type specifies that it is unique throughout the
document, but it seems like states/sends/invokes/data model fields would

all be in different namespaces (not to be confused with XML namespaces).

I would think it to be pretty useful for an <invoke> or a <send> to
share the ID of the <state> that contained it. If the intent was to
forbid this sort of thing, I think that should be explicitly stated.

6. Is the default transition on history states permitted to have
executable content? The algorithm seems to say no (the transition is
just used as though it were the history value), while section 3.11.2
does not say. If the answer really is "no", is there any reason to have
a <transition> child as opposed to just an attribute with the default
targets, other than consistency? (i.e. <history default="blah"/> seems
just as good as <history><transition target="blah"/></history>)

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit (i.e. it targets either itself or
another history state that then targets the original history state). A
potential solution (assuming no executable content from #6 above) would
be to simply forbid the default history state transition from having a
sibling history state as a target. There is no reason this would be
necessary, since A) before the history values are assigned, setting the
target of H1 to H2 would have the same result as setting the target of
H1 to the target of H2, and B) all sibling history state values are
assigned at the same time, which eliminates the default transitions --
there is never a time when one sibling history will be using its default

transition and the other will not.

-------------------
Lastly, here are some proofreading errors:

Section 3.2.2: Last paragraph -- in the text '...an "initial" attribute
or am <initial> element...', I'm assuming "or am <initial>" should be
"or an <initial>".

Sections 4.1.6, 4.3.3, E.1, E.7, G.1: The examples don't appear to have
been updated for the new expr and non-expr attributes.

Section 10.3.3.1: The XPath in the <assign> is incorrect.
"city[id='nyc']" should be "city[@id='nyc']".

Section B: addStatesToEnter() uses the "LCA" variable in its history
state handling, but it's never actually assigned a value. (I expect this

is from being moved from enterStates() in the previous WD, which means
that a likely correction is "root".)

Section C: scxml/@initialstate in the example should be scxml/@initial.
-------------------

Those are my comments for now. Thank you for your work on SCXML.

-- Greg

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

Re: [scxml] sixth WD of SCXML is published

2009-11-10T22:42:27Z

Hello. I have some more comments on the SCXML WD:

1. In section 3.5.2, where it says "the 'target' of the transition must
be a descendant of the <initial> element's parent <state>", was it
actually intended to say "descendant" and not "child" here? I ask
because if it is actually supposed to be "descendant", then there are
some issues that may need to be addressed regarding <initial> and
<parallel>. I can elaborate, but I want to make sure this is the case first.

-

2. Section 4.1.2 says that send/@namelist separates its datamodel
locations by space, but this is potentially incompatible with more
complex expressions. For example, the XPath expression:

a/b[@attr='some value']

...would be improperly broken at a whitespace boundary. The actual
method of specifying multiple names should probably be scripting
language-dependent. XPath has sequences (well, 2.0 does, anyway),
ECMAScript has arrays, etc.

-

3. The definition for <datamodel>/<data> is somewhat unclear. Section
5.1 says "...all instances of the <data> element are created and
initialized when the state machine is instantiated and may be accessed
from any state at any time." whereas 5.2 says "All <data> tags are
evaluated exactly once, at load time. Implementations thus MUST evaluate
<data> elements at load time but MAY do so in any order they choose."

Does this mean, then, that if I have something like <data id="someValue"
expr="random()" /> that all instances of a state machine in a particular
session will end up with the same value for "someValue" but that it may
differ if the SCXML document is reloaded?

If so, I assume the recommended alternative is to initialize the data in
scxml/initial/transition ?

-

4. What are the semantics of the in() predicate in any of the
intermediate places where executable content is used? What I mean by
this is that just about everywhere that executable content is used
except for transition/@cond, the current state configuration is in the
middle of being modified (onentry, onexit, (state |
parallel)/transition, initial/transition).

If the answer here is "add/remove states in the configuration when the
algorithm says so," then OK. I just wanted to make sure, since 8.1,
10.2.5.1, and 10.3.4.1 don't say anything about this.

-

5. parallel/history[@type = 'shallow'] -- Does it do anything useful? If
not, could it be made useful by digging down a little deeper to the
nearest children of a compound <state>? (Or does this stray too far from
Harel semantics?)

-

6. What happens if a <history> with no default transition is the target
of a transition? In the algorithm, it looks to me like this will create
an invalid state configuration. Maybe this should have the same defaults
that @initial does when unspecified?

-

7. When errors are raised at document load time, what is to be done with
them? Implementation-defined? I ask because they are formatted in the WD
as though they should be treated like dynamic errors (i.e. fed back to
the state machine as an event) but this is not possible without a state
machine instance. If I'm understanding correctly, the handling of these
two error types is *very* different -- static (document load) errors are
likely thrown as normal exceptions in whatever the implementation
language happens to be (e.g. Java exceptions), and dynamic (runtime)
errors are handled internally within the state machine without being
directly reported to the external environment (and potentially ignored
if there are no transitions to handle them).

-

8. I'm a little confused about scxml/@exmode='strict'. Section 3.1.1
says that the interpreter should raise "error.unsupportedelement" when
it encounters unrecognized executable content, whereas section F says
unrecognized custom executable content must raise an "error.badfetch"
event with scxml/@exmode='strict'. However, this is the only place
"error.badfetch" is mentioned. It also says
"error.unsupported.<element>" for unsupported SCXML elements. Which of
these three is it? (I understand there are going to be inconsistencies
of this nature in a work-in-progress, but I'm wondering which is the
most likely/recent candidate.)

Also, regardless of whichever error code it happens to be, I'm not sure
whether it's OK for me to make it a static error or if I have to wait
until runtime execution hits that point to raise the error. None of
sections 3.1.1, 3.12.6, or F give any clue if it's supposed to be static
or dynamic (or implementation-defined). At the moment, I just abort
compilation with a static error, since all possible custom executable
elements are known at compile time. I would guess implementation-defined
is the way to go, since nowhere does it say in the WD when custom action
elements must be bound to implementations (they could be bound pre- or
post-document load, or even dynamically in regards to the needs of the
document).

-

9. Are there any plans for state machine instance serialization? i.e. I
want to take a running instance, save its configuration, history states,
event queue, etc. to a byte array, and then restore it at a later time
(thus bootstrapping directly into a particular state configuration
rather than finding a way there from the initial state via the defined
transitions).

Obviously, things like serialization format and such would be
implementation-defined, but I ask because there are semantic
implications in how <onentry> and such might work. My current plan for
my own implementation is just that executable code in <onentry> can
access some extension variables and functions to determine if it's being
entered normally or entered as part of a serialized load.

My guess would be "No, there are no plans for this, and it's outside the
scope of the basic SCXML definition anyway." That's also fine, in which
case I guess I'm looking for any best practices suggestions.

-

That's it for now. Thanks for reading.

-- Greg

Re: [scxml] sixth WD of SCXML is published

2009-11-01T19:02:19Z

Kazuyuki Ashimura wrote:
> Hi www-voice,
>
> The sixth Working Draft of "State Chart XML (SCXML): State Machine
> Notation for Control Abstraction" has been published as follows.

Hello. My name is Greg Beauchesne. I guess I'm new here, but I've been
working on an SCXML implementation of my own and I figured that means I
should probably get in on this list.

So, without further ado...

1. I'm glad that the whole event name prefix issue has been updated to
use tokens. This had been causing me issues with event names like "up"
vs. "update".

2. Would it be possible for transition/@event to be of type NMTOKENS
instead of NMTOKEN? As it stands, if I want to have the same transition
be taken for two completely different events, with all of the associated
executable content, I have to copy and paste the entire transition
definition or otherwise use scripted functions to achieve common
functionality. I think this would not break anything, since NMTOKEN
already forbids whitespace. (Although technically I guess it's not
NMTOKEN anyway, according to the schema in D.1)

3. I also like the new expr vs. non-expr attributes; this really
clarifies when a string or expression should be used. On <send> and
<invoke>, I would say that @id and @idlocation is inconsistent with the
rest (@idexpr instead of @idlocation would probably match better), but
I realize this is probably for compatibility with previous WDs, not to
mention that it is the one attribute that acts as an lvalue.

4. Along the lines of the expr/non-expr attributes, I would see
value in something similar for <log>. It seems to me that @label is not
intended to be replacement for @expr (i.e. <log label="test"/> is not
necessarily the same as <log expr="'test'"/>, especially since @expr is
required and @label is not). So maybe something like <log message="My
message"/>?

If that were the case, though, it would probably get confusing as to
whether to use @label or @message. What was the intent behind the @label
attribute?

Alternatively or in addition, I think <log> could support child content
(at least text nodes) as an alternative to either the @label or @expr
attributes. <assign> and <data> already do this. For example, this:

<log>A thing happened</log>

....would be the same as this (assuming a compatible scripting language):

<log expr="'A thing happened'"/>

5. Section 9 on IDs does not specify the scope of uniqueness. I know
that the XML ID type specifies that it is unique throughout the
document, but it seems like states/sends/invokes/data model fields would
all be in different namespaces (not to be confused with XML namespaces).
I would think it to be pretty useful for an <invoke> or a <send> to
share the ID of the <state> that contained it. If the intent was to
forbid this sort of thing, I think that should be explicitly stated.

6. Is the default transition on history states permitted to have
executable content? The algorithm seems to say no (the transition is
just used as though it were the history value), while section 3.11.2
does not say. If the answer really is "no", is there any reason to have
a <transition> child as opposed to just an attribute with the default
targets, other than consistency? (i.e. <history default="blah"/> seems
just as good as <history><transition target="blah"/></history>)

7. The algorithm seems to potentially run into infinite recursion on
default history state transitions if multiple default history state
transition targets create a circuit (i.e. it targets either itself or
another history state that then targets the original history state). A
potential solution (assuming no executable content from #6 above) would
be to simply forbid the default history state transition from having a
sibling history state as a target. There is no reason this would be
necessary, since A) before the history values are assigned, setting the
target of H1 to H2 would have the same result as setting the target of
H1 to the target of H2, and B) all sibling history state values are
assigned at the same time, which eliminates the default transitions --
there is never a time when one sibling history will be using its default
transition and the other will not.

-------------------
Lastly, here are some proofreading errors:

Section 3.2.2: Last paragraph -- in the text '...an "initial" attribute
or am <initial> element...', I'm assuming "or am <initial>" should be
"or an <initial>".

Sections 4.1.6, 4.3.3, E.1, E.7, G.1: The examples don't appear to have
been updated for the new expr and non-expr attributes.

Section 10.3.3.1: The XPath in the <assign> is incorrect.
"city[id='nyc']" should be "city[@id='nyc']".

Section B: addStatesToEnter() uses the "LCA" variable in its history
state handling, but it's never actually assigned a value. (I expect this
is from being moved from enterStates() in the previous WD, which means
that a likely correction is "root".)

Section C: scxml/@initialstate in the example should be scxml/@initial.
-------------------

Those are my comments for now. Thank you for your work on SCXML.

-- Greg

[scxml] sixth WD of SCXML is published

2009-10-30T11:57:45Z

Hi www-voice,

The sixth Working Draft of "State Chart XML (SCXML): State Machine
Notation for Control Abstraction" has been published as follows.

This version:
http://www.w3.org/TR/2009/WD-scxml-20091029/

Latest version:
http://www.w3.org/TR/scxml/

Previous version:
http://www.w3.org/TR/2009/WD-scxml-20090507/

A diff-marked version is also available for comparison purposes at:
http://www.w3.org/TR/2009/WD-scxml-20091029/diff.html

The main difference from the previous draft is the correction of
various inconsistencies.

Comments are welcomed to this Voice public list, <www-voice@...>.

Best regards,

Kazuyuki Ashimura
for the W3C Voice Browser WG

--
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@...
voice: +81.466.49.1170 / fax: +81.466.49.1171

Changes to DOM3 Events Key Identifiers

2009-10-30T00:32:20Z

Hi, Folks-

(BCC to potentially affected groups: w3c-html-cg, public-webapps,
public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2,
public-html@..., www-voice... please forward on to any relevant
groups or individuals I may have missed, especially outside W3C.)

As editor of the DOM3 Events specification, I made what some may
consider to be drastic changes in the most recent drafts:
* I changed the syntax of the key identifier strings from "U+xxxx" (a
plain string representing the Unicode code point) to "\uxxxx" (an
escaped UTF-16 character string), based on content author and
implementer feedback.
* I renamed the "key identifier(s)" feature to "key value(s)".

I've mentioned these ideas before in DOM3 Events telcons, and finally
decided to do it, after first consulting with the I18n WG, who generally
approved of the scheme (though not without some comments about details
that will need to be addressed and resolved).

The new string format should be easier to deal with for developers, and
the new name reflects some confusion I've encountered when explaining
what "key identifiers" are... the work "identifier" seems to evoke the
concept of a unique identifier for a key, when in fact what the feature
does is provides the most appropriate value given the state of keyboard
modifiers and modes. I have tried also to clarify this in the prose of
the spec.

We are aware that there may already be implementations and
specifications that rely on the previous string format and name (as well
as links), back from when this was a W3C Note, and we do not make this
decision lightly, but we do believe this is the right decision for a
stable and internationalized keyboard interface going forward. For
those implementations and specifications that need the previous
functionality and name, you may be able to reference the SVG Tiny 1.2
specification [2] instead, which does include the old Key Identifiers
feature more or less intact from the previous definition, and is a
stable W3C Recommendation.

You can review the changes in the most recent Editor's Draft [1]. The
WebApps WG welcomes your feedback to the www-dom@... list. This
specification is still a work in progress, though we do hope to go to
Last Call soon, so we are open to suggestions. (Note that the spec is
mostly feature-complete, so new event types and other changes may have
to wait for the next version, but send them on anyway.)

[1]
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset
[2] http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet

Regards-
-Doug Schepers, on behalf of the WebApps WG
Editor, DOM Level 3 Events
W3C Team Contact, SVG and WebApps WGs

Re: Comments on CCXML specification - [cc] ISSUE-637

2009-10-22T02:49:06Z

Petr:

>> 3) Attribute 'info' in the conference.created and
>> conference.destroyed events - ISSUE-637
>>
>> Our idea to work around the problem (2) was to use the platform
>> dependent attribute 'info' in the conference.created event.
>> However, in contrast to the connection.* events there is no such
>> attribute in conference.created nor conference.destroyed events. Is
>> there any reason for this?
>>
>> Our suggestion is to add attribute 'info' to the conference.created
>> and conference.destroyed events with the same meaning this
>> attribute has in connection.* events.

This looks like an oversight in the specification. We will discuss
this on the next CCXML working group call and see if we can fix it in
the candidate recommendation.

Best regards,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

Re: Comments on CCXML specification - [cc] ISSUE-636 Named conference

2009-10-22T02:46:16Z

Petr:

>> 2) Named conference - ISSUE-636
>>
>> It would be useful in some applications to distinguish situations
>> when we really create a new conference and when we just get id of
>> an existing conference with the given name. Sometimes it is
>> necessary to perform a specific action when a conference is newly
>> created.
>>
>> Our suggestion is to add an attribute carrying this information to
>> the conference.created event. Analogously, we suggest to add an
>> attribute to the conference.destroyed event that will state that
>> the conference was really destroyed.

I agree this would be helpful for a number of applications. We will
look at adding this in CCXML 1.1.

Best regards,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

Re: Comments on CCXML specification - [cc] ISSUE-635 Attribute 'event' of the tag

2009-10-22T02:44:48Z

Petr:

>> 1) Attribute 'event' of the <transition> tag - ISSUE-635
>>
>> In some situations, several events are handled the same way. For
>> instance, after receiving connection.disconnected or
>> connection.failed the application typically exits. Since it is not
>> possible to specify more than one event in one transition (wild-
>> cards are not always sufficient) it is necessary to use more
>> transitions where event name is the only difference.
>>
>> Our suggestion is to allow the event attribute to specify more than
>> one value just as it is allowed for the state attribute:
>> "More than one value may be specified, separated by whitespace."

This sounds like a great idea and will be considered as a feature
request for CCXML 1.1.

Thanks for the great feedback.

Best regards,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

Re: Comments on CCXML specification - [cc] Number of conference participants - ISSUE-638

2009-10-22T02:40:42Z

Petr:

>> 4) Number of conference participants - ISSUE-638
>>
>> It is not possible to get information about the total number of
>> participants in a conference. The 'bridges' property of the
>> Conference object contains only the identifiers of connections/
>> dialogs within the current session. Connections/dialogs owned by
>> other sessions and joined to the same conference are not visible.
>> So it is not always possible to find out whether there are more
>> participants (and how many) in the conference.
>>
>> Our suggestion is to add a property to the Conference object that
>> would show the total number of connections/dialogs joined to the
>> conference.

This will be considered asa feature request for CCXML 1.1.

Best regards,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Editor and Chair, CCXML, VBWG, W3C

Re: Comments on CCXML specification - [cc] ISSUE-635 ISSUE-636 ISSUE-637 ISSUE-638

2009-10-22T02:37:23Z

Peter,

I have broken this into 4 issues that will be tracked individually.
They are listed below and I will send out follows to them individually.

> 1) Attribute 'event' of the <transition> tag - ISSUE-635

> 2) Named conference - ISSUE-636

> 3) Attribute 'info' in the conference.created and
> conference.destroyed events - ISSUE-637

> 4) Number of conference participants - ISSUE-638

RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Sep 18, 2009, at 11:57 AM, Petr Kuba wrote:

> Hello,
>
> We would like to suggest a few modifications and improvements of the
> CCXML specification that are motivated by our and our customers
> experience with building real-world CCXML applications. We believe
> that the suggested changes can be generally useful. In the same
> time, they are simple to incorporate into the specification and to
> implement.
>
>
> 1) Attribute 'event' of the <transition> tag
>
> In some situations, several events are handled the same way. For
> instance, after receiving connection.disconnected or
> connection.failed the application typically exits. Since it is not
> possible to specify more than one event in one transition (wild-
> cards are not always sufficient) it is necessary to use more
> transitions where event name is the only difference.
>
> Our suggestion is to allow the event attribute to specify more than
> one value just as it is allowed for the state attribute:
> "More than one value may be specified, separated by whitespace."
>
>
> 2) Named conference
>
> It would be useful in some applications to distinguish situations
> when we really create a new conference and when we just get id of an
> existing conference with the given name. Sometimes it is necessary
> to perform a specific action when a conference is newly created.
>
> Our suggestion is to add an attribute carrying this information to
> the conference.created event. Analogously, we suggest to add an
> attribute to the conference.destroyed event that will state that the
> conference was really destroyed.
>
>
> 3) Attribute 'info' in the conference.created and
> conference.destroyed events
>
> Our idea to work around the problem (2) was to use the platform
> dependent attribute 'info' in the conference.created event. However,
> in contrast to the connection.* events there is no such attribute in
> conference.created nor conference.destroyed events. Is there any
> reason for this?
>
> Our suggestion is to add attribute 'info' to the conference.created
> and conference.destroyed events with the same meaning this attribute
> has in connection.* events.
>
>
> 4) Number of conference participants
>
> It is not possible to get information about the total number of
> participants in a conference. The 'bridges' property of the
> Conference object contains only the identifiers of connections/
> dialogs within the current session. Connections/dialogs owned by
> other sessions and joined to the same conference are not visible. So
> it is not always possible to find out whether there are more
> participants (and how many) in the conference.
>
> Our suggestion is to add a property to the Conference object that
> would show the total number of connections/dialogs joined to the
> conference.
>
> Best Regards,
> Petr Kuba
>
> --
> Petr Kuba, Project Manager
> OptimSys, s.r.o
> kuba@...
> Tel: +420 541 143 065
> Fax: +420 541 143 066
> http://www.optimsys.cz
>

Re: CCXML: Message on Hold - ISSUE-634 [cc]

2009-10-22T02:26:03Z

Peter,

Thanks for this comment. We will consider this feature request in the
context of a CCXML 1.1 spec update. This is tracked as ISSUE-634.

Best regards.

RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Sep 18, 2009, at 2:40 PM, Petr Kuba wrote:

> Hello,
>
> We need to implement Message on Hold service in CCXML which will use
> SIP PBX instead of VXML dialog for playing music.
>
> Scenario for this service in SIP is described for instance here:
> http://www.tech-invite.com/Ti-sip-service-3.html
>
> The problem is that CCXML specification does not provide support for
> this operation. I've noticed that early version of the specification
> contained tag <hold> but later it was removed.
>
> Therefore it will be necessary to use some platform-specific (and
> thus non-standard) extensions. Since we are trying to follow the
> specification as much as possible we are looking for a solution that
> breaks the specification as little as possible.
>
> To the best of our knowledge, the only part of the CCXML
> specification that could be related to this problem is at the end of
> Section 10.2.1:
>
>
> "The PROGRESSING and ALERTING states have reflexive transitions.
> This is intended to model protocols which have additional states at
> these points, and which MAY exchange messages such as PROCEEDING,
> ALERTING, FACILITY, or NOTIFY. Platforms MAY choose to implement
> additional states which MAY be reflected in the substate property of
> the Connection object. Additional messages can be implemented with
> <send>."
>
>
> Our idea is to use the substate property of the Connection object to
> identify that a connection is on hold.
>
> To place a connection on hold and take it off hold we can probably
> use the <send> tag and send events (commands) to and from a
> connection. This would give us also flexibility for similar tasks in
> future.
>
> Unfortunately, sending events to and from a connection is mentioned
> only in the quotation above. We would appreciate more detailed
> description of this issue.
>
> We would also appreciate any comments on the suggested solution.
> Does this solution make sense? Do we miss something? Does anybody
> have better idea how to implement this? Has anybody implemented
> something like this?
>
> Thanks for responses,
> Petr Kuba
>
>
> --
> Petr Kuba, Project Manager
> OptimSys, s.r.o
> kuba@...
> Tel: +420 541 143 065
> Fax: +420 541 143 066
> http://www.optimsys.cz
>

Re: CCXML: using Object in the application scope - example error - ISSUE-633

2009-10-22T02:23:32Z

Petr,

This is tracked as ISSUE-633.

Thanks,

RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Sep 30, 2009, at 3:01 PM, Petr Kuba wrote:

> Hello,
>
> We believe that there is an error in the CCXML specification,
> section 8.4.
>
> The example in this section shows how to create an Object in the
> application scope:
>
> <var name="application.obj" expr="new Object()"/>
>
> We assume that behavior of the <var> tag should be the same as
> behaviour of a var statement within a <script> (although it is not
> explicitly stated in the specification). However, the following
> statement is not allowed in ECMAScript:
>
> var application.obj = new Object();
>
> However, it is correct to use the the following statement in
> ECMAScript:
>
> application.obj = new Object();
>
> Therefore we believe that correct version of the CCXML example is:
>
> <assign name="application.obj" expr="new Object()"/>
>
> In this case, the description above the example should be clarified
> as well.
>
> Thanks for response,
>
> Petr Kuba
>
>
> --
> Petr Kuba, Project Manager
> OptimSys, s.r.o
> kuba@...
> Tel: +420 541 143 065
> Fax: +420 541 143 066
> http://www.optimsys.cz
>

Re: Moving Form Events from DOM3 Events to HTML5

2009-10-11T03:00:17Z

Hi Doug,

I'd suggest we have a joint meeting during the upcoming
TPAC 2009 in Santa Clara about this.

I'll send another email to you and would like to discuss the
details.

Regards,

Kazuyuki

Doug Schepers wrote:

> Hi, Charles-
>
> Charles F Wiecha wrote (on 9/22/09 12:33 PM):
>> Hi Doug -- the more relevant reference for VoiceXML is the version 3.0
>> working draft [1] which does use DOM3 events. Charlie
>>
>> [1] http://www.w3.org/TR/2009/WD-voicexml30-20090825/#Eventing
>
> I stand corrected, thanks... that wasn't obvious from the VoiceXML
> homepage.
>
> I'm actually very encouraged that VoiceXML uses DOM3 Events... my
> previous impression from visiting VoiceXML and MMI events was that it
> didn't do so.
>
> I see that VoiceXML uses the DOM event flow model (minus capture
> phase?), and the Event, EventTarget, EventListener interface from DOM3
> Events, but I don't see any explicit use of any of the other
> interfaces or event types. I do see it has a <submit> element, but no
> mention of a 'submit' event. Is that correct?
>
> We are hoping to take DOM3 Events to Last Call in November, and we
> would much rather have major issues resolved before then, including
> comments from the XForms and VoiceXML folks. So, I would very much
> appreciate review and feedback of the Editor's Draft [1].
>
> [1]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

--
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@...
voice: +81.466.49.1170 / fax: +81.466.49.1171

Re: PLS errata hidden behind password

2009-10-03T20:19:41Z

Dear Nick Levinson,

Thank you very much for pointing out this.

We are very sorry we have been using a wrong configuration
for PLS Errata page, and also didn't get back to you earlier.

I have just fixed the access permission of the page and now
the PLS Errata page is publicly accessible.

Sincerely,

Kazuyuki

Nick Levinson wrote:

> Normally, when I retrieve errata for any document, they're just as available as the document itself. Only an extra click or two may be needed.
>
> However, the "errata" link on <http://www.w3.org/TR/pronunciation-lexicon/> has required a password for access. I can access PLS but not its errata.
>
> I assume W3C passwords are not available for the general public.
>
> I sent a message, I think to W3C's webmaster, about a couple of weeks ago or so, but I just tried the link again moments ago and it's still locked, and this seems unlikely enough to ask again.
>
> Could you please check whether passwording was intentional and, if not, ask someone to permit read-only access?
>
> Thank you.
>

--
Kazuyuki Ashimura / W3C Multimodal & Voice Activity Lead
mailto: ashimura@...
voice: +81.466.49.1170 / fax: +81.466.49.1171

PLS errata hidden behind password

2009-10-03T15:39:27Z

Normally, when I retrieve errata for any document, they're just as available as the document itself. Only an extra click or two may be needed.

However, the "errata" link on <http://www.w3.org/TR/pronunciation-lexicon/> has required a password for access. I can access PLS but not its errata.

I assume W3C passwords are not available for the general public.

I sent a message, I think to W3C's webmaster, about a couple of weeks ago or so, but I just tried the link again moments ago and it's still locked, and this seems unlikely enough to ask again.

Could you please check whether passwording was intentional and, if not, ask someone to permit read-only access?

Thank you.

--
Nick

CCXML: using Object in the application scope - example error

2009-09-30T06:01:15Z

Hello,

We believe that there is an error in the CCXML specification, section 8.4.

The example in this section shows how to create an Object in the
application scope:

<var name="application.obj" expr="new Object()"/>

We assume that behavior of the <var> tag should be the same as behaviour
of a var statement within a <script> (although it is not explicitly
stated in the specification). However, the following statement is not
allowed in ECMAScript:

var application.obj = new Object();

However, it is correct to use the the following statement in ECMAScript:

application.obj = new Object();

Therefore we believe that correct version of the CCXML example is:

<assign name="application.obj" expr="new Object()"/>

In this case, the description above the example should be clarified as well.

Thanks for response,

Petr Kuba

--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@...
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz

request

2009-09-30T02:33:33Z

Hi ,

i live in cameroon and i want a software , for callshop

where can i get it.

thank you

best regard

KANMEGNE KOUOMEGNE SIDNEY
INFORMATICIEN
NETWORKS AND SYSTEMS MANAGER
B.P 7332 DOUALA CAMEROUN
TEL: (237) 77 55 91 13
B: (237) 33 42 22 66

Re: Moving Form Events from DOM3 Events to HTML5

2009-09-22T10:38:09Z

Hi, Charles-

Charles F Wiecha wrote (on 9/22/09 12:33 PM):
> Hi Doug -- the more relevant reference for VoiceXML is the version 3.0
> working draft [1] which does use DOM3 events. Charlie
>
> [1] http://www.w3.org/TR/2009/WD-voicexml30-20090825/#Eventing

I stand corrected, thanks... that wasn't obvious from the VoiceXML homepage.

I'm actually very encouraged that VoiceXML uses DOM3 Events... my
previous impression from visiting VoiceXML and MMI events was that it
didn't do so.

I see that VoiceXML uses the DOM event flow model (minus capture
phase?), and the Event, EventTarget, EventListener interface from DOM3
Events, but I don't see any explicit use of any of the other interfaces
or event types. I do see it has a <submit> element, but no mention of a
'submit' event. Is that correct?

We are hoping to take DOM3 Events to Last Call in November, and we would
much rather have major issues resolved before then, including comments
from the XForms and VoiceXML folks. So, I would very much appreciate
review and feedback of the Editor's Draft [1].

[1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Bridging behavior clarification

2009-09-22T00:26:25Z

Hello,

Please consider the following code:

<join id1="X" id2="X"/>

This is a situation where a connection/conference/dialog is joined to
itself (loopback). We are not sure how to handle it and the CCXML
specification does not mention this case at all. We would appreciate
some clarification of this issue in the specification.

Although we are not sure whether this bahaviour is useful for a dialog
or a conference we have a use case for this code which involves
connection: It can be used for verifying phone line quality where a
testing equipment dials this service, plays tones and listens for these
tones back.

Our questions are:

1. Shall the duplex attribute of the <join> tag have value 'full' or 'half'?

2. Shall this join be allowed also for dialogs and conferences?

Thanks for clarification,

Petr Kuba

--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@...
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz

case-sensitivity & sentence structure

2009-09-20T15:24:01Z

Presumably, most TTS software knows that sentences begin with capital letters and standardizes pronunciations accordingly, probably by applying the pronunciation that applies to an all-lower-case form plus the slight emphasis that announces the start of a sentence.

However, a few words must be spelled in all lower case even at the beginnings of sentences, such as the names of most Linux program and a few authors (bell hooks and e.e. cummings). E.g.:

vi is a text editor. bell hooks probably didn't use it.

Other personal names begin in lower case even at the beginning of a sentence. E.g.:

deGraffenried is a jolly camper.

But a period may not signify the end of a prior sentence. E.g.:

We're glad that Ms. bell hooks is a prolific writer.

Contra:
Watch your Ns and Ms. bell hooks is a fastidious writer.

Various sentence structures, including multiple-sentence structures, have to be recognized, in PLS 1.0, <http://www.w3.org/TR/pronunciation-lexicon/>.

Thank you.

--
Nick

idiolectal pronunciation

2009-09-20T15:20:07Z

We need a way to classify a group of words that are too numerous to itemize and assign a set of pronunciation rules to that group.

Idiolectal pronunciations that have no grammatical or contextual cues other than who says them require selectors. (An idiolect is the language of one person; a dialect is what is common of the idiolects of two or more people who are of the same language community. Because English is spoken by a very large language community, its dialects combine into several standards, e.g., three standards in the U.S. and others in some other nations.)

This is for PLS 1.0, <http://www.w3.org/TR/pronunciation-lexicon/>.

I knew someone who had her own pronunciation of one word that often cropped up in her speech because of both her work and her nonwork life. Other than that word, while I'd recognize her voice, I don't recall a distinguishing accent. Were anyone to write a dialogue, we'd need a way to signify that the particular spelling represents a particular pronunciation only sometimes, a way that cannot be determined by syntax, sense, or part of speech.

A more common case in U.S. English is _nuclear_. Enough people repeatedly mispronounce it, including a former U.S. President, to constitute a use case. One big-city mayor and large-business owner consistently says /anyways/ in public where the orthography probably would be "anyway", and so do other people.

Aliases can be used, but we need a way to signify when to invoke them.

If role and xml:id don't serve that purpose, I propose the class and id attributes as used in (X)HTML. A class or id attribute would appear in the original Web page. The .pls document would specify one pronunciation for a given class or id and a default pronunciation when no class or id applies.

With the adoption of the id attribute, I propose also the adoption of the name attribute, to be reserved and denied any meaning. In (X)HTML, name is being phased out but is still widely deployed in older pages and in pages written to be compatible with older browsers, where typically both id and name are assigned the same values. Therefore, PLS cannot allow a different meaning for name than for id, unless it ignores name's value altogether.

The class would be handy for a dialogue, as in a movie script. In a dialogue, each person has thir own paragraphs, so each (X)HTML paragraph could be assigned a class, e.g. <p class="chris">. Selected words within the paragraphs could be given matching classes, e.g., <phoneme class="chris">.

Thank you.

--
Nick

pronunciation rules for types of symbols

2009-09-20T15:12:23Z

We need a way to classify a group of words that are too numerous to itemize and assign a set of pronunciation rules to that group. This is for PLS 1.0, <http://www.w3.org/TR/pronunciation-lexicon/>.

Symbols in a category are an example. Explanatory prefixes exclusively for speech might be desired, because the visual representation is more informative than a literal speaking would usually be. E.g.:
%33
/percent thirty-three/: confusing to the unfamiliar public
/percent-encoded percent three three/: prefixed

While programmers understand %33, the public doesn't. A string like %67%75%80%75 read literally and without an explanation will confuse most of the public.

A character entity might appear in a natural-language string solely because HTML requires it for proper rendering by one user agent, but pronunciation may have to treat it differently. E.g., for &:
/ampersand a m p semicolon/: literal & confusing to most listeners
/ampersand amp semicolon/
/ampersand amp/: the semicolon seems like ordinarily silent punctuation
/character entity ampersand a m p semicolon/
/character entity for ampersand/
/ampersand/: formal interpretation
/and/: semiformal interpretation

On the other hand, silencing of what is visible might be appropriate. It nmight be desired to read long runs of "0x62356 0x8172367 0x8364856 0x865892 . . ." without pronouncing the hex visual prefixes.

I'm not sure if the lexeme element's role attribute would solve this problem. If role is too specific, I propose a new attribute, perhaps number-role or super-role, the latter supporting more values, such as "number-year" and "number-quantity".

I assume role can already handle formality. If not, I propose an attribute: formality="" with values "formal", "semiformal", and "informal", and probably others.

Quantities are not supposed to be pronounced with "and" except at the location of a decimal point, e.g., six and three fourths, although perhaps informality allows it.

Thank you.

--
Nick

pronunciation that is font-sensitive

2009-09-20T15:09:41Z

When fonts are mixed in order to acquire a symbol needed for math, such as a dot at half the x-height as a multiplication symbol, that may require that a pronunciation be font-sensitive.

This is for PLS 1.0, <http://www.w3.org/TR/pronunciation-lexicon/>.

An alias and an id attribute would support unique pronunciations for strings, but a method to support categories of pronunciations is needed.

Font sensitivity could also support different voices for main text and for callouts and quotations within the main text, although for that other methods might be available.

Thank you.

--
Nick

pronunciation rules for types of numbers

2009-09-20T15:06:46Z

We need a way to classify a group of words that are too numerous to itemize and assign a set of pronunciation rules to that group. This is for PLS 1.0, <http://www.w3.org/TR/pronunciation-lexicon/>.

Numbers are an example. One range of numbers might serve as years or as single-moment quantities and therefore be pronounced differently. The same range might be pronounced formally or semiformally and still need to be correctly distinguished. E.g.:
/eighteen twenty-two/: year semiformal
/eighteen hundred and twenty-two/: year formal
/eighteen hundred twenty-two/: quantity semiformal
/one thousand eight hundred twenty-two/: quantity formal
/eighteen hundred and twenty-two/: incorrect for quantity
/one thousand eight hundred and twenty-two/: incorrect for quantity
/one comma eight two two/: proofreader's style
/one eight two two/: radio style likely in air traffic control and military

I'm not sure if the lexeme element's role attribute would solve this problem. If role is too specific, I propose a new attribute, perhaps number-role or super-role, the latter supporting more values, such as "number-year" and "number-quantity".

A range of numbers should be definable by specifying the smallest, the increment (e.g., integer), and the largest. That could determine whether a number might be a year; if the choice is between year and quantity and the number doesn't fit the specification for being a year then it must be a quantity.

I assume role can already handle formality. If not, I propose an attribute: formality="" with values "formal", "semiformal", and "informal", and probably others.

Quantities are not supposed to be pronounced with "and" except at the location of a decimal point, e.g., six and three fourths.

It's technically incorrect to read aloud "33" as /thirty-three/ if the "33" is not in base 10. Even if the base doesn't have to be read aloud because the context makes it clear, a nondecimal-base "33" would be read as /three three/.

Other number pronunciation ambiguities exist. E.g.:
/one point two/
/one and two tenths/

Or consider 102.204/16:
/one oh two dot two oh four slash sixteen/: IPv4 IP address range
/one hundred two and two hundred four thousandths divided by sixteen/: arithmetic

Or U.S. Zip codes used by the post office: E.g., for New York, N.Y.:

10001
/one triple oh one/
/one thousand one/
(I don't think I've ever heard anyone say /ten thousand one/ for that zip code, and I live in the city.)

10036
/one double oh thirty-six/
/one double oh three six/
/one oh oh three six/
/one oh oh thirty-six/

Or Brooklyn:
11201
/one twelve oh one/

Or 6-2:
/six two/: e.g., Class 6-2 in an elementary or middle school
/six dash two/
/six to two/: sports score
/six hyphen two/: proofreader's style
/from six to two/: e.g., an 8-hour work shift
/six minus two/
/six less two/
/six take away two/: for children as the audience

Or more complicated math, including one character having two senses:
([5+3][{4-1}x2]/x)
/the quotient of the product of the sum of 5 and 3 and the product of the difference of 4 minus 1 times 2 divided by x/

Or this, for, e.g., 1011b:
/one oh one one binary/
/one thousand eleven bits/
/one thousand eleven bytes/

Thank you.

--
Nick

CCXML: Message on Hold

2009-09-18T05:40:47Z

Hello,

We need to implement Message on Hold service in CCXML which will use SIP
PBX instead of VXML dialog for playing music.

Scenario for this service in SIP is described for instance here:
http://www.tech-invite.com/Ti-sip-service-3.html

The problem is that CCXML specification does not provide support for
this operation. I've noticed that early version of the specification
contained tag <hold> but later it was removed.

Therefore it will be necessary to use some platform-specific (and thus
non-standard) extensions. Since we are trying to follow the
specification as much as possible we are looking for a solution that
breaks the specification as little as possible.

To the best of our knowledge, the only part of the CCXML specification
that could be related to this problem is at the end of Section 10.2.1:

"The PROGRESSING and ALERTING states have reflexive transitions. This is
intended to model protocols which have additional states at these
points, and which MAY exchange messages such as PROCEEDING, ALERTING,
FACILITY, or NOTIFY. Platforms MAY choose to implement additional states
which MAY be reflected in the substate property of the Connection
object. Additional messages can be implemented with <send>."

Our idea is to use the substate property of the Connection object to
identify that a connection is on hold.

To place a connection on hold and take it off hold we can probably use
the <send> tag and send events (commands) to and from a connection. This
would give us also flexibility for similar tasks in future.

Unfortunately, sending events to and from a connection is mentioned only
in the quotation above. We would appreciate more detailed description of
this issue.

We would also appreciate any comments on the suggested solution. Does
this solution make sense? Do we miss something? Does anybody have better
idea how to implement this? Has anybody implemented something like this?

Thanks for responses,
Petr Kuba

--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@...
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz

Comments on CCXML specification

2009-09-18T02:57:02Z

Hello,

We would like to suggest a few modifications and improvements of the
CCXML specification that are motivated by our and our customers
experience with building real-world CCXML applications. We believe that
the suggested changes can be generally useful. In the same time, they
are simple to incorporate into the specification and to implement.

1) Attribute 'event' of the <transition> tag

In some situations, several events are handled the same way. For
instance, after receiving connection.disconnected or connection.failed
the application typically exits. Since it is not possible to specify
more than one event in one transition (wild-cards are not always
sufficient) it is necessary to use more transitions where event name is
the only difference.

Our suggestion is to allow the event attribute to specify more than one
value just as it is allowed for the state attribute:
"More than one value may be specified, separated by whitespace."

2) Named conference

It would be useful in some applications to distinguish situations when
we really create a new conference and when we just get id of an existing
conference with the given name. Sometimes it is necessary to perform a
specific action when a conference is newly created.

Our suggestion is to add an attribute carrying this information to the
conference.created event. Analogously, we suggest to add an attribute to
the conference.destroyed event that will state that the conference was
really destroyed.

3) Attribute 'info' in the conference.created and conference.destroyed
events

Our idea to work around the problem (2) was to use the platform
dependent attribute 'info' in the conference.created event. However, in
contrast to the connection.* events there is no such attribute in
conference.created nor conference.destroyed events. Is there any reason
for this?

Our suggestion is to add attribute 'info' to the conference.created and
conference.destroyed events with the same meaning this attribute has in
connection.* events.

4) Number of conference participants

It is not possible to get information about the total number of
participants in a conference. The 'bridges' property of the Conference
object contains only the identifiers of connections/dialogs within the
current session. Connections/dialogs owned by other sessions and joined
to the same conference are not visible. So it is not always possible to
find out whether there are more participants (and how many) in the
conference.

Our suggestion is to add a property to the Conference object that would
show the total number of connections/dialogs joined to the conference.

Best Regards,
Petr Kuba

--
Petr Kuba, Project Manager
OptimSys, s.r.o
kuba@...
Tel: +420 541 143 065
Fax: +420 541 143 066
http://www.optimsys.cz

Re: Question on SRGS spec and IR

2009-09-14T10:05:05Z

I haven't seen any response to this. Can we get some guidance?

Ian Sutherland wrote:

The VoiceXML Forum is extending its platform certification test suite with a number of tests based on the SRGS 1.0 IR, and a question's come up about a test involving setting the base URL via a <meta> tag. In the IR test "metabase-declaration.grxml", there's a <meta> element
<meta name="base" content="./test/"/>
Judging from the description of the input and output in other <meta> elements and the contents of the "test" subdirectory, this seems intended to set the base URI for resolving <ruleref> URIs. However, the SRGS 1.0 recommendation seems somewhat divided on this. In section 4.11.1, it says
The seeAlso property is the only defined meta property name.
and
It is recommended that for general metadata properties that grammar authors follow the metadata properties defined in the Dublin Core Metadata Initiative [DC].
In section 4.9, however, it says
Note: the base URI may be declared in a meta declaration but the explicit base declaration is recommended for both the ABNF Form and XML Form.
So, it seems like the recommendation says that the base URI is settable by a <meta>, but it doesn't say how, the exact syntax for doing so is specified only in the IR, and the recommendation says that the name for setting the base URI in a <meta> is not defined. What's the resolution of this? Should the recommendation be amended? (The errata has no errata.) Should this test not have been in the IR?

[ian_sutherland.vcf]

begin:vcard fn:Ian Sutherland n:Sutherland;Ian org:Oracle USA Inc.;Voice Lab adr:233 South Wacker Drive;;Suite 4500;Chicago;IL;60606;United States of America title:Consulting Member of Technical Staff tel;work:1-312-651-8169 note:The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. x-mozilla-html:FALSE version:2.1 end:vcard