RE: SCXML is possibly useful for a play list (was Re: Gap analysis: SCXML (was Re: Gap analysis: SMIL))

For our products, we have selected SCXML for "managing" events (not implemented yet in our solution, but it is really missing)
We have to deal with remote-controls, buttons, events sent by network, time events, ... and mix all together to take decisions about what to play (control layer).

The concept of event is for us not enough. We need the concept of state (state machine). SCXML seem to be a good way to declare states (as datamodel).
Then the implementation can be native or javascript (we will probably prefer native).


Samuel GALLACIER 

INNES
ZAC Atalante Champeaux
5A rue Pierre Joseph Colin
35000 RENNES
FRANCE
 
Tel  : +33 (0)2 23 20 01 62
Fax : +33 (0)2 23 20 22 59
 
www.innes.pro

-----Message d'origine-----
De : Kazuyuki Ashimura [mailto:ashimura@w3.org] 
Envoyé : jeudi 10 janvier 2013 12:02
À : public-websignage@w3.org
Objet : Re: SCXML is possibly useful for a play list (was Re: Gap analysis: SCXML (was Re: Gap analysis: SMIL))

On 01/10/2013 06:37 PM, Sangwhan Moon wrote:
> Hello all,
>
> On 1/10/13 5:01 AM, Kazuyuki Ashimura wrote:
>> On 01/09/2013 08:55 PM, Futomi Hatano wrote:
>> I think using SCXML for a play list (or history of all the play 
>> lists) would be a great idea.  Also I 100% agree with you SCXML would 
>> fit the use for control layer.
>>
>> FYI, as you might know, SCXML is expected to be used as the 
>> Interaction Manager (=controller layer) for MMI Architecture [1].
>> For example, one possible example of MMI-based multimodal Web 
>> applications is a voice-ready game application which has GUI as well.
>> And it could consist of the following three parts:
>>
>> - SCXML-based Controller: Interaction Manager of MMI Architecture
>>    which controls the flow of the game application
>>
>> - VoiceXML-based speech interface: Voice Modality Component of MMI
>>    Architecture which handles speech input/output
>>
>> - HTML5-based graphical interface: GUI Modality Component of MMI
>>    Architecture which handles keyboard/touch panel input and display
>>    output
>>
>> Please see also the MMI Interoperability test report at:
>>   http://www.w3.org/TR/mmi-interop/
>> for the details of the example.
>>
>>  > We can handle SCXML using JavaScript.
>>  > 1. Get a SCXML file specified in JS or HTML from the originated 
>> web server using XHR.
>>  > 2. Parse the SCXML file using DOM3Core.
>>  > 3. Show each content (e.g. an ad) marked up in HTML based on the 
>> scenario defined in the SCXML.
>>
>> I agree handling SCXML as a data format to describe play lists using 
>> JavaScript would be also a good idea.
>
> If it's a linear or simple branching playlist, using a state machine 
> for this is overkill. And it would be good to keep in mind that XML is 
> also less memory/processor cycle efficient than say, JSON when it 
> comes to parsing and storing, due to the structural overhead.

Probably we should concentrate on use cases and gap analysis first.

And I personally think one of possible use cases is that advanced vending machines (e.g., [1] and [2]) have kind of complicated process flow and they even could store whole purchase history of each specific user identified by his/her credit card or stored fair card in the near future.

BTW, probably it would make sense to describe both pros and cons of each existing standard which could be used for the use cases identified in the use cases/requirements document, wouldn't it?

[1] http://en.rocketnews24.com/2011/08/09/2075/
[2] http://www.youtube.com/watch?v=tPdbFKNY4r8

>>  > The declarative approach is for a basic (simple) case.
>>  > I think we don't need to consider all use cases.
>>  > If we use SCXML for a play list, it could be simple.
>>  >
>>  > How do you think this combination approach?
>>  > If you agree with this idea, I'll add SCXML in the gap analysis 
>> for R1.
>>  >
>> http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cas
>> es_and_Requirements#R1._Making_contents_using_a_declarative_approach
>>
>>
>>  >
>>  > If my understanding of SCXML is wrong, let me know.
>>
>> As I mentioned above, I think the combination approach is a great 
>> idea.
>
> We will put SCXML on the table for potential candidates, but 
> considering that there is a larger parsing/storing overhead to be used 
> on the client side along with the fact that there are no native 
> implementations, and it is unclear if we want to document anything 
> related to the server side (if you see the requirement document, it's 
> mostly user agent level requirements) so we should probably stop this 
> discussion here and get back on track on triaging the other requirements first.
>
> I would like to politely note that technology advocacy is *not* the 
> main purpose of this group, and we should go for the most suitable 
> solution that is also easy for content developers to start using based 
> on already existing implementations - mostly because our deliverable 
> should be something that can be used right away, and especially since 
> the group does not have strong enough influence on what browser 
> vendors will (or will not) implement as it is setup right now.

Agree.

Thanks,

Kazuyuki

--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170

Received on Friday, 11 January 2013 11:56:11 UTC