W3C home > Mailing lists > Public > public-websignage@w3.org > December 2012

Re: Re[6]: Gap analysis: SMIL

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Thu, 06 Dec 2012 19:56:26 +0100
To: "Kai Hendry" <hendry@webconverger.com>, "Futomi Hatano" <futomi.hatano@newphoria.co.jp>
Cc: public-websignage@w3.org
Message-ID: <op.wowr8ca7y3oazb@chaals.local>
I note that the Gap Analysis  

"There are two ways to..."

I think you mean

"At least two possible ways have been proposed to..."

(more detail below. Basically I think rejecting SMIL out of hand is as  
pointless as assuming that we should just demand complete implementations  
of SMIL 2.0 in browsers... it is worth thinking about what is actually  
necessary and valuable)


On Thu, 06 Dec 2012 16:54:12 +0100, Futomi Hatano  
<futomi.hatano@newphoria.co.jp> wrote:

> On Thu, 6 Dec 2012 21:20:12 +0800
>> On 28 November 2012 17:47, Futomi Hatano

> Although I'm not sure if SMIL is used widely or not,
> it's true that SMIL is used in signage industry and
> there are signage operators who want to enhance SMIL.
> The doc reflects the statements for the workshop held at Japan in June  
> this year.
> W3C Workshop on Web-based Signage
> http://www.w3.org/2012/06/signage/agenda.html
>> > From what I've seen in the DOOH signage industry, vendors tout all
>> > sorts of crazy proprietary technologies which doesn't make their
>> > approach right.
>> > A declarative approach make developing CMSs easier.
>> > If we can use CMSs for signage contents, creating content will
>> > be cost-effective.
>> I don't think there needs to be any special language changes to
>> support a Web signage CMS.
> Me too.

That depends on what he requirements are. If one of those is "Meet the  
other requirements using only open standards",

> "A declarative approach" mentioned in the doc doesn't mean
> creating new languages nor changing existing languages.

It does if the platform doesn't support the requirements.

>> > I can't imagine using Google docs for creating signage contents.
>> > How do you control playlists? How do you control transition effects?
>> http://support.google.com/drive/bin/answer.py?hl=en&answer=1708414

What does this actually *produce*? Google Docs isn't suitable to be a W3C  
standard (or even a Web standard).

>> > How do you control durations for each ads?
>> File -> Publish to Web, "Automatically advance presentation to the
>> next slide" has a duration dialog.
> If Google docs is a good solution for creating contents for signage,
> why isn't it used in signage industry?

It isn't a standard, it is a proprietary technology belonging to a single  
company, and there are a number of reasons why companies would not be  
prepared to make an industry rely on a single company, and instead develop  
standards to achieve the same goals.

>> > Existing HTML CMSs such as Google docs don't meet even the
>> > requirement for the "Basic advertisement".
>> I think it does. People use it already like this.
> For signage? I didn't know that.
> Could you show us some actual cases in which Google docs are used
> for signage contents?

I am sure they do. But recommending a *company* (or their product) as a  
standard is a very bad idea.

>> And this is a very simple example, of course a proper CMS designed for
>> creating signs can do a better job.
> Yes.
>> > If SMIL were implemented in ordinary web browsers,
>> > the sentence would be correct.
>> > We listed all possibilities in the "Gap analysis".
>> > Of course, I know it's unlikely actually.
>> > But no one can bet that for now.
>> It's extremely unlikely. I don't understand how you can seriously
>> consider adding SMIL onto the Web.

I would not add all of SMIL into the web. But significant and important  
parts are already there. The animation spec, which allows for things that  
CSS animation cannot handle, is effectively implemented through SVG in  
multiple browsers.

The ability to provide par and seq is pretty trivial, and pretty useful.  
Although it isn't done in HTML5 media the requirements to handle track,  
and the work on adaptive streaming, together implement the two pieces -  
which are not exactly complex. Equally, these could be faked to a certain  
extent on top of event-based animation.

> You misunderstand me.
> I don't back up SMIL.
> In the doc, it is simply listed as a possibility.
>> Isn't it a better approach to list the problems of the Web in detail
>> instead of introducing an entire technology stack?


> The doc isn't a specification nor a standard.
> It's just a material for further discussion.


> The doc doesn't determine using SMIL for Web-based Signage.

It describes use cases, and requirements. It doesn't say "use company X'  
software, because the goal is to develop standards that anyone can use".

Without saying that we should simply implement SMIL everywhere, I think it  
is equally senseless to simply reject everything from SMIL out of hand. It  
may be the easiest way to meet requirements, or it may introduce problems  
far worse than those it solves. But I don't think the case has been proven  
either way.

>> > Could be.
>> > But I think it isn't big advantage.
>> > I've never heard such scenario.
>> > If I were an advertiser, I would prepare dedicated contents
>> > for PCs or smartphones.

If I were a high-value advertiser, I probably would too. I would still  
appreciate them using the same platform, and that platform making it more  
efficient to adapt content to different devices without repeating work.

But if I were a small government department producing disaster information  
that will hopefully never be necessary, or a small ad-hoc organisation of  
people producing important content for whatever devices can be used after  
a disaster has occurred, I would like to be able to do this simply,  
declaratively, as much as possible relying on widely-implemented standards.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Thursday, 6 December 2012 18:57:07 UTC

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