Re: SMIL content for specific calendar time ranges

On 28 mei 2010, at 16:21, Sanja C. wrote:

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

First thing you should realize is that the SMIL State definition is a two-stage process. The SMIL State chapter sets out general guidelines and defines the elements and attributes and what they should do. How this is then integrated in a language (such as the SMIL 3.0 language) is then defined in the Language Profile. 

The SMIL 3.0 Language Profile defines that at least XPath must be allowed as the expression language (but implementations may provide support for other languages too). In <http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-profile.html#SMILProfileNS-state-module>, around the sixth paragraph, it also states that serialization (if you use the XPath language) should be done according to what the XForms spec says. And it says "use XML".

But: implementations can extend this, for example by allowing a second language to be used. For example, some versions of the Ambulant SMIL player allow not only XPath and XML to be used as the SMIL State expression language, but also Python. This extension was done purely on the whim of one of the implementors (i.e. me:-), a more logical "second expression language" would be JavaScript. Note that the language used inside the state element (and the external representation) is tied to the expression language: only for XPath as expression language is it defined you must use XML as the data language.
> 
> 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?

It is not defined, it is considered out of scope for the spec. Ambulant without any extensions does not provide any way for an external agent to change a state variable (although the SMIL presentation itself can get a new collection of state variables through use of the <send> and <submission> elements, but this mechanism is intended more for things like filling out forms).
But Ambulant extensions can do this easily, and we ourselves have used various methods to change state variables inside a running presentation:
- an XMLRPC server implementing set/get/del methods,
- a miniature webserver providing a form with buttons that change state variables,
- internal logic 

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

You caught us there: we overlooked this, and we didn't realise it until the spec was out. The SMIL spec specifically states that the expr attribute is evaluated when the element carrying it becomes active. This is distinct from the {var} construct in an attribute, which is explicitly re-evaluated if it changes during an elements lifetime. In hindsight we should have allowed both interpretations in both situations.

Luckily, there is a workaround that can be often (but not always) be used:
  <ref title="Happy hour page" restart="always" begin="0;xxx.stateChange(happyHour)" expr="happyHour"/>

There is even a method to have this activate/deactivate in sync (for example for switching audio tracks in parallel with a continuous video track) but that is so gross I'll keep it to myself unless someone wants it:-)
> 
>> [...]
>> 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.
> 
> 
> 
> 
> 

--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Monday, 31 May 2010 21:19:21 UTC