Re: Gap analysis: SMIL

On 12/07/2012 03:56 AM, Charles McCathie Nevile wrote:
 > I note that the Gap Analysis
 > 
<http://www.w3.org/community/websignage/wiki/Web-based_Signage_Use_cases_and_Requirements#Gap_analysis> 

 > says
 >
 > "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)

Agree.

For example, as I mentioned at the Web-based Signage Workshop in June
[1], even SCXML could be another "related existing standard" here.

Also we should concentrate on thinking about "what is actually
necessary and valuable" as Charles mentioned above rather than
rejecting any possibilities at least at the gap analysis stage.

FYI, SCXML has just been published as a LCWD.

Please see:
  http://www.w3.org/TR/2012/WD-scxml-20121206/

[1] http://www.w3.org/2012/06/signage/minutes

Thanks,

Kazuyuki


 > cheers
 >
 > 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?
 >
 > Naturally...
 >
 >> The doc isn't a specification nor a standard.
 >> It's just a material for further discussion.
 >
 > Right.
 >
 >> 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.
 >
 > cheers
 >
 > Chaals
 >


-- 
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170

Received on Thursday, 6 December 2012 19:55:55 UTC