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

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.

>  > 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.

Thanks,
Sangwhan

Received on Thursday, 10 January 2013 09:38:18 UTC