- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 10 Jan 2013 05:01:27 +0900
- To: public-websignage@w3.org
On 01/09/2013 08:55 PM, Futomi Hatano wrote: > Hi Kaz, Sangwhan, Hi Futomi, Happy New Year! And thanks a lot for your thoughtful comments. Could you please see my responses inline below? > Thanks for the discussion on SCXML. > I've thought about SCXML. > As the subject of this post, SCXML is possibly useful for a play list. > IMHO, SCXML isn't likely to be a solution for presentation layer. > But it's likely to be some kind of metadata for controlling contents. > I think that we can use HTML/CSS/JS for a presentation layer and > SCXML for a control layer. 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. > 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_cases_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. BTW, do you think you could provide comments on SCXML from that viewpoint to the VBWG, because SCXML is now on its LCWD stage and the LC period is ending shortly? Just mentioning the above combination idea is fine, and it would be even greater if you could provide some additional comment like "It would be better for signage services if SCXML has some additional capability on ...". [1] http://www.w3.org/TR/2012/REC-mmi-arch-20121025/ Thanks, Kazuyuki -- Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice Tel: +81 466 49 1170
Received on Wednesday, 9 January 2013 20:02:04 UTC