W3C home > Mailing lists > Public > public-websignage@w3.org > January 2013

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

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 10 Jan 2013 20:02:12 +0900
Message-ID: <50EE9FB4.3040508@w3.org>
To: public-websignage@w3.org
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_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.
> 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.




Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Thursday, 10 January 2013 11:02:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:23:26 UTC