Re: SMIL content for specific calendar time ranges

Hi Jack,

thank you for your reply.

> The slightly longer answer is that it is possible by using a tiny external agent (or script). SMIL State (see http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-state.html) was specifically designed with this use in mind (among other things): the whole SMIL presentation is declarative, with some parts based on SMIL State variable(s). This variable is then changed by the external agent.
> [...]
>  <state xmlns="">
>    <data>
>      <year/>
>      <month/>
>      <day/>
>      <weekday/>
>      <hour/>
>    </data>
>  </state>
> your example B could now be coded as
>   <ref expr="weekday=7 and hour &gt; 9 and hour &lt; 18" title="specialOverlay"/>

This does indeed look very promising, I like the flexibility it would imply regarding all kinds of complex states we might like to add in the future (which for example a custom SMIL extension for recurring wallclock event timing would not give us). Together with the basic SMIL 3.0 Tiny stuff (and possibly BasicTransition) this might just be all we need.

What I can't gather from the SMIL State w3c recommendation, however, is:

1) What kind of source file does the "source" attribute of the "state" element expect? Is this completely unspecified/client-specific?

2) Does any standardization (official or inofficial) exist regarding how external agents change state variables of a running SMIL presentation? (e.g. a SOAP schema or something for communication between the player and the external agent over HTTP or other means). How do implementations like GRiNS/ambulant handle this?

3) When exacly is the expression in the "expr" attribute of an element evaluated (and acted upon)? Only when the element is about to be shown, or is the expression also recalculated on each state change event? I.e. in the following example, will the Happy hour page not only appear when "happyHour" becomes true, but also disappear once it becomes false again?
<excl duration="indefinite">
    <seq title="Normal presentation" begin="0" repeatCount="indefinite"> ... </seq>
    <ref title="Happy hour page" expr="happyHour"/>
</excl>

> [...]
> Many more wild things are possible with SMIL State, let me know if you're interested and I can point you to a paper we wrote on the subject.

Yes, I'm definitely interested :-)


Greg,

On Fri, May 28, 2010 at 1:44 AM, Herlein Greg <greg_herlein@prn.com> wrote:
> PRN uses SMIL for our playlists on our newer generation digital signage systems.  We found that wallclock within the SMIL playlist was not suitable, partly since we wanted to essentially schedule playlists and not have to a) send wholly rebuilt playlists, or b) have to parse a large playlist just to get to a portion that applied to a certain day part, and c) we wanted to be able to replace portions of playlists scheduled independently.  We designed a schedule mechanism using XML that is SMIL-like but is not SMIL and use that to meet the discrete needs of digital signage.  We've share that publically with the POPAI Digital Signage Technical Standards group.  Sanja, contact me directly from your company and I'll see if we can work out a way to share it with you.

I've stumbled upon http://www.a-smil.org/index.php/Wallclock in the meantime, describing simple "Repeated Date/Time Events" wallclock scheduling for SMIL, specifically intended for digital signage, by allowing "R/.../.." specifiers in wallclock time values. Is your solution also along those lines?

While this kind of extension/modification to SMIL would provide support for the case of weekly or similarly scheduled items, the State mechanism as pointed out by Jack appears to be a much more flexible and probably also cleaner solution at least for our purposes, with the added benefit of being officially SMIL compliant, so I'd like to try and pursue that path first. If it doesn't work out, I might get back to you though.

Received on Friday, 28 May 2010 14:21:53 UTC