The value promise of the motion model is not limited to synchronization. This
section presents key properties of the media model that is implied by the
motion model.

\runinhead{Decoupling media components from online motions:} 

Motion objects in the Web browser decouple media components from online
motions. For Web developers, this means that the problem of media
synchronization is reduced to component synchronization, essentially an
exercise in regular Web programming (see Sect.~\ref{sec:compsync}). This way,
globally synchronized media components and Web experiences may be built by
practitioners with limited competence in distributed synchronization.
Furthermore, a standardized API for motion would allow media products to
easily exploit the combined power of very different media components and media
technologies. It would also ensure reusability of media components, for
example across applications, across live and on-demand media, or for offline
usage. Offline synchronization may be supported by a local motion object (i.e.
not connected to an online motion). A standardized API for motion would also
open up for alternative implementations of motion synchronization.

\runinhead{Decoupling motion from media content:}

The motion model describe how media components connect to online motion, yet
it does not include any references to media content. This is on purpose. In
the motion model, online motion is separate from content transfer, which is
considered an independent problem. In particular, the service hosting online
motion is not required to host any media content at all\footnote{Online motion
should preferably be hosted by a dedicated service, thus avoiding disturbances
resulting from unrelated server-side processing or bandwidth consumption.}.
Instead, media components will fetch their media content from other resources
or services. Strict isolation of online motion ensures that no restrictions
are put on media components regarding choice of media formats or transport
mechanisms. By implication, the motion model supports synchronization across
any media format or transport protocol\footnote{Media content must refer to a
timeline, in order for media components to be able to synchronize it with
online motion.}.

\runinhead{Decoupling media components from each other:}

The motion model adopts the client-server architecture of the Web. This allows
media components to remain independent of other media components. This is
important. For example, a failing media component should not be allowed to
halt an entire distributed media experience. Moreover, independence of media
components yields other important properties, such as flexibility,
extensibility, dynamism, and reduced complexity. In addition, independence of
media components simplifies development and testing, as well as integration of
media products across different technologies and platforms.

\runinhead{Online media control:}

In the motion model, Web availability is achieved by representing media
control and an online resource. Online media control implies that media
control requests (e.g. pause/resume) target the online motion, and only
affects media components after the result is communicated
back\footnote{Favouring responsiveness over synchronization, it would be
possible for a media component to implement the effects of a media control
request speculatively, before sending it to the online motion. This feature is
not a part of the model, but may be implemented in application code if needed.
}. Importantly, this means that synchronized media experiences based on online
media control are remote controllable by design, from any connected device.
This allows multi-device media experiences to make control features available
from multiple devices or views, as opposed to depending on a single, dedicated
control device. By adding access control to online motions, media control
privileges may be appropriately restricted.


\runinhead{Dynamic participation:}

The Web environment is characterized by high \emph{churn}, i.e. Web clients
may be expected to disconnect and reconnect at any time. To support this,
clients must be able to join and leave a synchronized media presentation
without disrupting other clients, or the presentation itself. The client-
server architecture of the Web makes this easy. For instance, reloading a
synchronized Web page is simply a matter of disconnecting from, and
reconnecting to, an online motion. Note also that online motions do not depend
on connected clients for their existence. If an online motion is requested to
play, it will continue to do so until requested otherwise, even if all media
components have disconnected. This allows a Web client to occasionally peek
into an ongoing media presentation, even if no other clients are
watching\footnote{Whether the media presentation exists or not, when no media
components are connected to the online motion, remains a philosophical
question.}. This is what is typically expected from live media productions.


\runinhead{Symmetry:}

Asymmetric master-slave synchronization is a common pattern in media
synchronization. The pattern implies that a set of media components (slaves)
are synchronized relative to a specific media component (master). In the
motion model all media components are slaves, and the motion is the master.
This way, the motion model avoids added complexities of the master-slave
pattern, and provides a symmetric model where each media component may request
control via the motion. If asymmetry is more appropriate for a given
application, this may easily be emulated. For instance, applications may
ensure that only a specific media component may issue control requests to the
motion.

\runinhead{Internal Synchronization:}

At present, external synchronization is the common pattern on the Web, where
media components are coordinated by manipulating their control primitives.
Unfortunately, media components on the Web have not been particularly designed
with synchronization in mind. Also, external synchronization generally gets
more difficult as the number of components increases. Heterogeneity in media
types and control interfaces complicate matters further. In contrast, internal
synchronization is the pattern implied by the motion model, where media
components synchronize themselves relative to an external motion. In this
pattern, precise media synchronization may be implemented with unrestricted
access to the internal state and capabilities of the particular media
component. Furthermore, the synchronization task is shifted from Web
developers using the component, to the author of the media component. This
ensures that the problem may be solved once, instead of repeatedly by
different application developers.


\runinhead{Single-source media components:}

Dealing with multiple media assets, one approach is to collect them into
standardized file or container formats. This approach allows co-transport of
multiple media sources (as one source), and requires a media player supporting
the particular transport protocol and media format. The motion model enables
the opposite approach, where each media component is dedicated to a single
content source. This removes the need for bundling content sources, and allows
an appropriate transport mechanism to be selected for each content source. For
instance, subtitle-tracks do not have to be bundled with video files, but may
instead be represented as online resources. This way, media providers may even
edit them real-time, while they are being displayed for content viewers.
Importantly though, the motion model leaves the design choices regarding media
transport and media sources entirely to developers. Existing container-based
media frameworks are fully compatible with the motion model, provided only
that they may be controlled by motion (see Sect.~\ref{sec:html5sync}).

\runinhead{Single-purpose media components:}

In the motion model, media components may also be specialized with respect to
purpose. For instance, a single media component may implement interactive
controls for motion, thereby relieving other media components from the
complexity of this function. This encourages a pattern where media components
are designed for specific roles in an application, e.g. controllers, viewers
and editors, and combined to form the full functionality. Even though these
media components are independent, appropriate layout and styling may hide
this, giving the impression of a tightly integrated media product.

