On 12/25/2012 05:28 PM, Sangwhan Moon wrote:
> Been stuck in a project that needed a bit more immediate attention,
> and this reply has been rotting in my draft box for the last couple
> weeks.
>
> ...apologies.
>
> On 12/11/12 10:07 AM, Futomi Hatano wrote:
>> On Mon, 10 Dec 2012 16:55:04 +0900
>> Kazuyuki Ashimura <ashimura@w3.org> wrote:
>>
>>> BTW, I think my point is:
>>>
>>> - We should not restrict the possibilities of any existing
>>> approaches/mechanisms including SCXML, CSS, SVG and SMIL, at this
>>> stage, i.e., Gap Analysis.
>>>
>>> - We should not jump into technical details at this stage, though
>>> detailed discussions on possible implementations/services should
>>> follow.
>>>
>>> - We should involve all the stakeholders and get their opinions as
>>> well. For example, we should ask all the participants in the June
>>> workshop [1] to provide their views.
>
> I do agree that we should not put too hard of constraints on the what
> kind of approaches that the group will take to tackle the use cases,
> but we *do* have to be realistic.
>
> Unless we can get commitment from at least two browser vendors that a
> certain specification that we bring to the table will be implemented,
> putting that into a best practice document would make the document
> itself a lost cause.
>
> As for SCXML, at least Opera has no plans to _natively_ support it.
>
> I cannot speak for any other browser vendor, but it does not seem like
> there is any native implementation in any browser at the moment from a
> quick investigation, and I couldn't find any backlog of such work being
> tracked either.
Hi Sangwhan,
Thanks for your comments.
I think one of the points here is what the scope of the Web-based
Signage BG is.
The BG's page [1] says:
[[
The goal of the group is to identify use cases and system image/model
for expansion of web browser based digital signage and smarter
integration of existing Web standards.
]]
And my understanding is that "Web-based Signage Use Cases" can include
some system which consists of (one or more) Web Browsers and (one or
more) SCXML-based servers. For example, Innes said they used SCXML for
their signage services, but I don't think it meant they implemented a
Web browser which included SCXML.
So I'd suggest we have two sections (or subsections) for the
requirements document, i.e., one for client-side technology and
another for server-side technology (or combination of servers
and clients using WebSocket, etc.).
> I _did_ find this: https://github.com/jbeard4/SCION
>
> I believe the largest problem is the amount of complexity that SCXML
> brings to the table versus the amount of use cases it solves.
I'm not sure a (simple) signage use case needs all the features
of the SCXML specification. Maybe we can define a signage profile
for SCXML (or HTML5, CSS3, etc.) if needed, can't we?
In any case, I'm not saying we have to include SCXML in the requirements
document, but I don't think there is any reason to exclude it at the
use cases and requirements stage given there is a use case.
BTW, when I attended the Web and Automotive Workshop in November [2],
Audi said they used SCXML for their in-car systems, that could be also
a kind of Web-based signage use case, I think.
[1] http://www.w3.org/community/websignage/
[2] http://www.w3.org/2012/11/14-webandauto-minutes.html
Thanks,
Kazuyuki
> If there is a *absolute* need for a declarative model for timed
> elements that cannot be covered with a imperative development model
> (Javascript), we should try to find a pragmatic and simple solution
> that is readily available and allows the developers to write content
> immediately, rather than rely on a standard where the implementation
> status of browsers or learning curve may slow them down.
>
> I have yet to take a look at web animations, that could be a possibility
> - although I'm still trying to get my head around the bit if there is a
> absolute necessity for the above-mentioned declarative model.
>
> Sangwhan
>
--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170