Re: CCXML: comment on ISSUE-729

Petr,

Admittedly, there are a number of square pegs that don't fit into round 
holes here. What I mean by that is
the following:

1) CCXML has a defined interface to receive unsolicited asynchronous 
HTTP events; VoiceXML2.0/2.1 does not.
2) CCXML's standard event attribute table(9.4.2.2) lists attributes that 
should be
present on CCXML events; but often they don't apply (Example: eventid 
from a basichttp? what is that supposed to be?)
3) CCXML section K says eventsource is optional; 9.4.2.2 says it is required

In your example where <send> is used within CCXML to talk to another CCXML
the eventsource would be set by the sender because it makes sense -  the 
sender can be
reached at a URI (which is the value of 
session.ioprocessors["basichttp"]). That URI is
its well defined basichttp interface listed in section K. I don't see 
how this example
is related to what we are discussing because VoiceXML has no such 
equivalent defined
HTTP interface(#1 above), and eventsource is optional when received via 
basichttp (#3 above).

 >>Regarding the issue I reported, could you explain me how you guess 
the value of the eventsource in your Event I/O Processor?

It doesn't. Section K says eventsource is optional (See #3 above). My 
comment yesterday was for the
required attributes through section K, not of 9.4.2.2. Sorry about that 
confusion.

 >>And are you able to use this value to send an event from CCXML to 
VoiceXML using basichttp?

No. VoiceXML has no defined HTTP interface to receive unsolicited 
events. We "send events" to
VoiceXML through a custom interface (not HTTP) only for things like 
<dialogstart> and <dialogterminate>
and as part of VXML <transfer>.
In those cases we map back to the IPC mechanism via the dialogid.

I suggested that we reject your issue because you are suggesting a 
resolution that requires VoiceXML
(the app, not the internals) to require a minimum of *FIVE* arguments on 
the namelist instead of 2
when communicating to CCXML (name, sessionid,eventid,eventsource, and 
eventsourcetype).
The preferred alternative is just name and sessionid for any <data> usage.

Of those extra 3 args, eventsource and eventsourcetype have no meaning 
coming from VoiceXML.
eventid also has no explained value as CCXML only wants it to match the 
<send> but it didn't even
come from <send> in this case.

If something can be done with 2 arguments instead of 5, is it a better 
interface?

Regards,
Chris

Petr Kuba wrote:
> Hello Chris,
>
> My understanding of "It is the responsibility ... to make sure that 
> they are present." is that the Event I/O Processor should REJECT any 
> events that do not contain required attributes not that it should 
> create them.
>
> Especially in case of eventsource the Event I/O Processor can hardly 
> know what value should be used. The eventsource value specifies a URI 
> to which events may be sent. It means that the sender must fill it in 
> to inform the receiver how to answer.
>
> Imagine a situation where one CCXML interpreter sends an event to 
> another one using basichttp. The Event I/O Processor of the target 
> CCXML interpreter cannot create eventsource attribute because it 
> doesn't know id of the session that sent the event, the URI of the 
> sending CCXML platform and it doesn't even know that he is receiving 
> event from another CCXML platform. So the format and structure of the 
> eventsource is completely unknown for the receiving Event I/O Processor.
>
> You are correct that VoiceXML is not an I/O processor. In the issue I 
> reported it must be responsibility of the VoiceXML script to insert 
> eventsource value into the <data> tag. VoiceXML implementation doesn't 
> have to know anything about the CCXML internals. Only the application 
> programmer has to know it (and it is OK).
>
> Regarding the issue I reported, could you explain me how you guess the 
> value of the eventsource in your Event I/O Processor? And are you able 
> to use this value to send an event from CCXML to VoiceXML using 
> basichttp?
>
> I believe that you are wrong in your understanding and there is no 
> point to reject the issue.
>
> Regards,
> Petr
>
> On 2.8.2010 18:41, Chris Davis wrote:
>> Hello www-voice,
>>
>> The question:
>> -------
>> "Who is responsible for inserting the required attributes in this case
>> where the event is sent from a VoiceXML application using basichttp? I
>> assume that it is responsibility of the VoiceXML application."
>> ----------
>> I think the answer is "the basic http processor is responsible", because
>> 9.4.2.1 says:
>> "It is the responsibility of the Event I/O
>> Processor that delivered the event to make sure that they are present."
>>
>> VoiceXML is *not* an I/O processor. By definition, the <data> work
>> is flowing through the basichttp processor that translates HTTP into 
>> CCXML
>> events.
>>
>> My understanding of the section of 9.1 that Petr quoted refers to 
>> users of
>> CCXML <send> who do not format their events correctly and so it doesn't
>> apply here.
>>
>> We recommend this issue be rejected for the above reasons. A positive 
>> side
>> effect is that VoiceXML also needs to know less of the internals of 
>> CCXML
>> (eventid, eventsource, and eventsourcetype).
>>
>> Regards,
>> Chris
>>
>>
>> On Jul 26, 2010, at 3:15 AM, Petr Kuba wrote:
>>
>>> Hello www-voice,
>>>
>>> In 7_2, the 'dialog.user.test' event is rejected because it doesn't
>>> contain required attributes eventid, eventsource, and eventsourcetype
>>> (according to the CCXML specification, sections 9.4.2).
>>>
>>> Section 9.1 states:
>>>
>>> "Platforms SHOULD reject any standard events that do not contain all
>>> of the mandatory properties defined in this specification, and SHOULD
>>> notify the sender of the rejection (for instance with an error.send
>>> event)."
>>>
>>> Who is responsible for inserting the required attributes in this case
>>> where the event is sent from a VoiceXML application using basichttp? I
>>> assume that it is responsibility of the VoiceXML application.
>>>
>>> Please clarify and fix the test.
>>>
>>> Thanks,
>>> Petr
>>
>
>


-- 
Chris Davis
Interact Incorporated R&D
512-502-9969x117

Received on Tuesday, 3 August 2010 16:18:08 UTC