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

On Thu, 10 Jan 2013 20:02:12 +0900
Kazuyuki Ashimura <ashimura@w3.org> wrote:

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

SCXML could be used for such advanced vending machines.
But I don't think it's best for the use cases.
If I were to develop it using web technologies, I would use
only JavaScript like web apps (or web games).

Anyway, though I proposed a way to use SCXML as a play list,
this doesn't mean that I support SCXML.
I just show one of the possibilities for R1.
If I set your expectations, I'm sorry in advance.

To be honest, I believe that XML-based solutions such as SCXML
won't be accepted by developers (including me) in practice
at this time.

Of course, I don't deny potential of SCXML for eternity.
I think that our "Use cases and Requirements" shouldn't deny
possibilities regardless whether it's the best solution or not,
because no one can bet which solution is the best at this time.

How about adding this phrase in the gap analysis for R1.

[[
SCXML
When contents are separated to a presentation layer and a control layer,
it's possible to use HTML/CSS for a presentation layer and SCXML for a control layer. 
]]

Then I'd like to finish this topic.
SCXML isn't the main topic in this group.

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

As Sangwhan mentioned, we should get back on track on triaging
the other requirements first.
SCXML has very very low priority in my mind.
No one (except Kaz) supports SCXML in this group as far as I know.
At least Sangwhan and I are skeptical of SCXML.

I'm afraid that we don't have time to discuss SCXML first.


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

Cheers,
Futomi

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Friday, 11 January 2013 01:15:28 UTC