Re: SMIL content for specific calendar time ranges

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

> Hi Jack,
>=20
> thank you for your reply.
>=20
>> 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=3D"">
>>   <data>
>>     <year/>
>>     <month/>
>>     <day/>
>>     <weekday/>
>>     <hour/>
>>   </data>
>> </state>
>> your example B could now be coded as
>>  <ref expr=3D"weekday=3D7 and hour &gt; 9 and hour &lt; 18" =
title=3D"specialOverlay"/>
>=20
> 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.
>=20
> What I can't gather from the SMIL State w3c recommendation, however, =
is:
>=20
> 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.=20

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#SMILProfil=
eNS-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.
>=20
> 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=20

>=20
> 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=3D"indefinite">
>    <seq title=3D"Normal presentation" begin=3D"0" =
repeatCount=3D"indefinite"> ... </seq>
>    <ref title=3D"Happy hour page" expr=3D"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=3D"Happy hour page" restart=3D"always" =
begin=3D"0;xxx.stateChange(happyHour)" expr=3D"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:-)
>=20
>> [...]
>> 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.
>=20
> Yes, I'm definitely interested :-)
>=20
>=20
> Greg,
>=20
> On Fri, May 28, 2010 at 1:44 AM, Herlein Greg <[email protected]> =
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.
>=20
> 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?
>=20
> 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.
>=20
>=20
>=20
>=20
>=20

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