How Does SMIL Communicate State to a Server?

Synchronized Multimedia Integration Language (SMIL) communicates client-side runtime state back to an authoring or backend server primarily through the SMIL StateSubmission Module introduced in the SMIL 3.0 specification. By coupling an internal XML data model with declarative submission elements—specifically <submission> and <send>—a SMIL presentation can capture user inputs, track playback progress, and transmit structured data over protocols such as HTTP without requiring custom scripting.

The SMIL 3.0 State Architecture

In earlier versions of SMIL, presentations were predominantly unidirectional. Player runtimes evaluated static switch conditions or local system metrics, but they lacked a standardized way to modify and persist internal variables. SMIL 3.0 introduced dedicated State modules—drawing inspiration from XForms and XPath—to allow dynamic state handling:

SMIL UserState Module: Defines the presentation's internal data model using elements like <state>, and provides control elements like <setvalue>, <newvalue>, and <delvalue> to update document variables dynamically.
SMIL StateSubmission Module: Defines transmission rules and execution triggers that package this state data and dispatch it to an external endpoint.

The Core Submission Elements

State transmission relies on two coordinating elements: <submission> and <send>.

1. The `<submission>` Element

Declared within the document's <head> or state declaration area, the <submission> element specifies the connection parameters for the external endpoint:

action: The destination URL where the state payload will be sent.
method: The transport method, typically standard HTTP verbs such as post or put.
ref: Specifies which subset of the internal state tree or node set to transmit.
replace: Instructs the player how to handle the server's response. Options include:
none: Ignores the server's reply and continues playback uninterrupted.
instance: Replaces the local state data model with the XML payload returned by the server.
all: Replaces the entire SMIL document with the new document returned by the server.

2. The `<send>` Element

While <submission> defines how and where data travels, the <send> element defines when the submission occurs. Because <send> participates directly in SMIL's timing engine, submissions can be scheduled precisely or tied to interactive user triggers:

<smil xmlns="http://www.w3.org/ns/SMIL" version="3.0" baseProfile="Language">
  <head>
    <state language="http://www.w3.org/2007/SPARQL">
      <data xmlns="">
        <score>85</score>
        <completed>true</completed>
      </data>
    </state>
    <submission id="submitScore"
                action="https://example.com/api/progress"
                method="post"
                replace="none" />
  </head>
  <body>
    <par>
      <!-- Media playback and user interaction -->
      <video src="lesson.mp4" id="lessonVideo" />
      
      <!-- Trigger submission when video reaches the end -->
      <send submission="submitScore" begin="lessonVideo.end" />
    </par>
  </body>
</smil>

Practical Applications of State Communication

By combining <state>, <setvalue>, and <send>, SMIL presentations maintain a continuous feedback loop with authoring servers:

Learning Management Systems (LMS): Tracking student responses, quiz answers, and module completion in interactive educational media.
Digital Signage Analytics: Reporting playback health, ad impression timestamps, and localized device telemetry back to central content managers.
Dynamic Content Personalization: Updating the client's internal data tree via replace="instance" to tailor downstream branching paths based on server-side business logic.