Our operating environment can vary from a 20MHZ CPU with 320x480 16color graphics, to a CPU operating at over 200MHZ with1024x768 32bit color graphics. Though the higher-end environment is much more capable, it is nowhere near as capable as today’s desktop PCs. With this consideration, implementing the full SVG specification becomes too cumbersome; we are thus limited to the mobile profiles.
Upon examination of the 1.2 (and 1.1) Mobile profiles, we find that SVG Basic is only possible on the high-end platforms. Additionally, SVG Tiny is much too restrictive, even for the low-end platforms. SVG Tiny restricts reference to the current page, does not allow for gradients (restricted on 1.2) and does not support enough functionality to meet our product’s core functional requirements. Though the low-end platforms support only 16 colors, the CLUT organization is very conducive to linear gradient vertical patterns – which is in high use in our current product.
From the definition of XML Events, and DOM level 3 events, we assume that we will be able to abandon our key binding element in favor of the, very similar, standard format. However, interactivity issues still remain. Due to the constraints (listed above), scripting is not always possible, or acceptable.
The current product boasts a minimum 80Kbyte virtual machine and more than 750K bytes of presentation data. This leaves very little room for class files, xml data and applications. Thus, classes that support scripting must be limited to allow for applications and xml data to exist on the low-end platform. Further, by limiting the amount of script necessary, we increase the likelihood of compatibility among various platforms (assuming platforms may have DOM and/or script sub-sets).
For these reasons, we would like to propose a new profile specifically targeted to our industry’s (the digital cable television industry) needs. Similar W3 specifications have already produced standards for this market segment (i.e. the CSS TV Profile). Below is our recommendation for an SVG TV profile to be part of the mobile profile specification. We’ve taken the liberty to define inclusion and compatibility as well as to identify areas of concern. This may not be a complete list. We realize the timing of this submission may be less than optimal and we apologize for the inconvenience, and thank you for your consideration.
The following
lists elements included in the SVG TV profile. Except as noted below, SVG TV
supports each listed element’s full definition. SVG TV supports XMLEvents.
SVG TV should be
a proper subset of SVG (it may be necessary to extend SVG core to maintain
proper subsetting).
Structure
defs,
desc, g, metadata, svg, title, use
Painting
Basic Graphics Attribute Module
Hyperlinking
a
Conditional Processing
switch
Shapes
circle,
ellipse, line, path, polygon, polyline, rect
Images
image
Text
text,
tspan, tref, textPath
Gradients
linearGradient,
stop
Fonts
font,
font-face, font-face-name, font-face-src, glyph, hkern, missing-glyph
Document Events Attribute Module
Graphical Element Events Attribute Module
Animation Events Attribute Module
Timing Events
Attribute Module
clipPath, mask
Animation
animate,
animateColor, animateMotion, animateTransform, mpath, set
Extensibility
foreignObject
audio, video, par, seq
SVG TV may support a variant of the ‘handler’ element. The ‘handler’ element may contain, or refer to, SVG element definitions. This ‘handler’ may specify a type of ‘image/svg’.
The contents of the ‘handler’ are not rendered until the event occurs.
This method is preferred, to limit the number of content type players that must co-exist in a constrained environment. Scripting should be minimized.
An alternative is to not support ‘handler’, but to support DOM level 3 events and SMIL ‘accesskey’ attributes. However, the ‘accesskey’ attribute must support DOM level 3 key identifiers.
The ‘tref’ element shall be fully supported. Elements that are referenced by the ‘tref’ element may exist outside of the current document (unlike SVG Tiny). Additionally, Elements that are referenced, by the ‘tref’ element, must resolve to a form that is acceptable for text rendering (i.e. PCDATA|TextContent.class ).
In the event that the referenced object does not resolve to a format compaitable with ‘text’, the reference must be ignored.
The ‘linearGradient’ element
SVG Tiny 1.2 support of gradient patterns is acceptable with the following modifications: percentages on stop values should be allowed. The ‘xlink:href’ attribute should be allowed.
SVG TV must support linear gradient patterns along the vertical viewing plane. SVG TV may support linear gradient patterns in the horizontal direction. Optional, horizontal, patterns should be encapsulated within a ‘switch’ element, defining the ‘externalResourcesRequired’ attribute.
The ‘Timing Events Attribute Module’
It is
necessary to provide a ‘quiescientTime’ attribute in the ‘svg’ element. This
attribute defines an amount of inactivity time (time with out user input events
– Graphical Element Events) that can occur before a suitable inactivityTimeOut
event is generated.
Inactivity
time out is necessary so that: 1) the user is not presented stale content, 2)
the displayed content does not fall out of context, 3) Damage to CRT devices
does not occur (i.e. Screen Saver).
Inactivity
time out handlers may be specified in the XML Events format.
SVG Tiny 1.2 provides many new methods that are accessible from script. However, setting timeout intervals and binding timeout events are not, yet, defined by any Mark-up. It is acceptable to bind generic timeout intervals and provide an ‘ontimeout’ attribute in the ‘svg’ element. However, the timeout value must be modifiable (preferably through markup) so that it may be reset on user input (in support of the inactivity criteria defined above).
The ‘image’ element
User Agents may support the SVG 1.2 image element. However, implementation of JPEG and PNG image rendering is not guaranteed on all platforms. Image elements should be encapsulated by a ‘switch’ element, defining an appropriate URI for the ‘requiredExtensions’ attribute. SVG TV SHOULD NOT be required to support JPEG and PNG image formats. Test attributes should be added to the ‘image’ element to facilitate conditional rendering.
Compatibility
Emerging W3 specifications are focused on the television market segment. SVG TV should consider, at a minimum, inclusion of the CSS TV Profile.
Tighter SMIL integration allows for a reduced number of UA to integrate on the platform. SVG TV should consider integration of basic layout from SMIL.
Additional UAs may be required for various presentations. The ‘foreignObject’ element is viewed as suitable for such extension.
Areas of Concern:
The
‘foreignObject’ element
The ‘foreignObject’
element does not define transformation or aspect ratio attributes. It is
possible to inherit these attributes, and other styling, from an ‘image’
element, but, the ‘image’ element must be allowed to reference a
‘foreignObject’.
Layout
Both SMIL and SVG do
not allow layout relative to other visible elements. A previous proposal
allowed element attribute access – similar to what is done in SMIL animations.
This would allow elements to align themselves relative to other elements. The
following illustrates this approach:
<rect
id=”boundingRectangle” x=”20%” y=”20%” width=”60%” height=”60%”
fill=”blue”/>
<text
x=”boundingRectangle.x” dx=”10%+” y=”boundingRectangle.y” dy=”10%+”
fill=”white”>HELLO THERE</text>
The above
illustration would bind the text element to the upper coner of the rectangle.
Although this may be less than optimal, it provides a simplified alternative to
layout, without specifying element-region fill attributes (such as top, left,
right, center, etc., as in some lay out managers). Additionally, this approach
may lessen the burden on constrained environments (such as the Tiny and TV
environments) by eliminating the need for many ‘flow’, ‘layout’ and/or ‘region’
elements (with possible deep nesting).
Further, this would
allow a presentation to maintain spacing as resolution changes; Allowing the
same presentation to be consistent among various resolutions. This approach may
also allow elements to be bound around the perimeter of other elements.
It is noted that the
above example could be solved as:
<text
id=”encapsulatedText” x=”20%” dx=”10%+” y=”20%” dy=”10%+” fill=”white”>HELLO
THERE</text>
<<rect
width=”60%” height=”60%” fill=”blue”><set
begin=”encapsulatedText.load”
attributeName=”y” to=”20%”/>
<set
begin=”encapsulatedText.load” attributeName=”x” to=”20%”/>
However, note that
the ‘x’ and ‘y’ coordinates cannot be bound to one another.
Another proposal (in
draft form) identifies a ‘bind’ element to provide the functionality described
above (see ‘Attribute Binding’ defined in ‘BAM’, http://www.schepers.cc/BAM).
It may be necessary
to provide basic operators in attribute value specifications such as: <… x=”r.x+r.width+10” …/>
A similar approach
has been developed as an extension to batik:
http://www.csse.monash.edu.au/~clm/csvg/extension.html
.
The ‘pattern’ element
Unfortunately, the
‘pattern’ element is used only in the context of filling and stroking. Thus,
elements, defined within the ‘pattern’ element, cannot receive focus (are not
navigable). A suitable means of tiling groups of elements must be created to
allow for grids and lists of information to be presented in a meaningful
fashion.
Elements, within
such organization, shall be able to receive focus. Additionally, each element
should be able to be tiled with relative spacing between siblings. Further, the
Elements should be able to take presentation description from out side sources
(i.e. from CGI return, external documents, etc.).
Such organization is
necessary to reduce Mark-Up file size, for constrained environments.
While the ‘flow’
elements seem to give such logical ordering, they do not present an idea of
regions that can be defined relative to one another. Additionally, ‘flow’
elements are primarily focused on text presentation. Further, ‘flow’ elements
do not define methods by which ‘flowRegions’ may be tiled.
SMIL ‘region’ and
‘layout’ elements won’t permit repetition of ‘regions’ in a layout.
Key event binding
User input devices
vary among the television platforms available. Almost all platforms translate
input into character encodings. However, many of these encodings are not within
the printable characters. Extensions must be provided to allow ‘handler’
elements and/or SMIL derived elements to be associated with a key event,
specified by key identifier.
It is not enough for
an action to be bound to a ‘keypress’ event. Actions must be filtered to the
unique key identifier to provide meaningful interaction. Currently, this would
require scripting – which would be cumbersome in many television environments.
Navigation
Navigation has been
largely delegated to the UA implementation. This presents a problem for digital
cable systems (as does scripting).
Deployment of
applications, in a cable system, require system certification from a suitable
test facility – a lengthy process. This certification is done based on relative
vulnerability. That is, if the application modifies or allocates system
resources, or violates basic system behavior, then the application is ‘high
risk’ and must be thoroughly tested.
It is in the Cable
Operator’s best interest to minimize certification test runs. This allows Cable
Operator’s to deploy more rapidly, meeting particular marketing requirements.
It also allows Cable Operator’s more flexibility and freedom in controlling
their cable systems.
In order to meet this
goal, scripting should be minimized (as it may influence system behavior, in
un-documented ways). Additionally, navigation – suggested or fully specified –
should be well defined.
The ‘focus’ property
The ‘focus’ property
helps to define navigation and event handling, as well as determining
navigability. However, much of this property remains un-defined (as noted in
the current working draft). Additional areas to consider include: propagation
of events to child elements (assume that a container element is given focus),
navigation within a group, further definition of event cancellation, and visual
representation of focus.
Propagation of
events should occur if the focus element is a container, has child elements,
has child elements that define event listeners. The order of propagation is TBD
(i.e. does the container act on it first, or do the children).
Navigation within a
group should be possible. Whether or not the nav-index is relative to the group
or page is TBD. The nav-index should be modifiable via mark-up (i.e. via the
‘set’ element).
Cancellation of
events, or indicating event consumed, assumes that there is some method of
propagation. However, the specification does not define what the propagation
is. Further, cancellation should be accessible via mark-up. Perhaps consumption
can be indicated in a property or attribute. It may also be possible to simply
define the behavior: The event is consumed by the first element that defines a
listener for the event – the listener may do nothing.
Visualization of
focus should be defined. For instance, if an ‘a’ element is focused, the first,
renderable, encapsulated element should receive the focusIn event in order to
modify its appearance appropriately. An alternative may be to propagate the
focusIn event. Further, it is possible to specify that the first renderable
element should receive the highlight and delegate the visualization of the
highlight to the UA.
Further concern
surrounds the application of focus, itself. If multiple children have a ‘focus’
attribute set to true, which element actually receives the focus, visual
highlight, and events?
SVG TV should
support CSS3 BUI ‘Directional Focus navigation’, ‘Sequential navigation order’,
and ‘Keyboard equivalents’. All properties should be modifiable by mark-up
(i.e. the ‘set’ element).
Copy
protection
Many television
systems utilize Macrovision copy protection techniques. These are federally
mandated in some areas. There must be support for enabling and disabling
Macrovision copy protection, as well as identifying its state in the media
stream. This capability must be supported in the mark up.
Content Advisory
With respect to the
‘video’ and ‘audio’ elements, test attributes must exist that define rating for
the respective material that is consistent with rating systems in the
geographical region (this might be best handles as style properties). SVG TV
MUST support the SMIL Content Control Modules and must allow for custom test
generation. An alternative is to define the tests necessary for ratings based
Content control/filtering (and copy protection).
URLs
URLs do not
accommodate aspects of broadcast file systems. Nor do they fully accommodate
selection of media elements in a broadcast system. As such, elements should be
allowed to specify URL’s that have: transport specifications outside of the
recognized – named – protocols and have varying formats for server
identifications (beyond host:port). The second enhancement is to support:
selection of service stream (in-band or out-of-bound), selection of service
component and – possibly – selection of file system root (which has
ramification to MHP and OCAP security policies). MHP and OCAP have provided
extensions to the URL format for these, but they are divergent (both must be
supported). Reference: “Multimedia Home Platform 1.0.2 DVB Blue Book A057
Rev.2”, EBU – UER. Reference: “OpenCable Application Platform Specification
OCAP 1.0 Profile OC-SP-OCAP1.0-I06-030430”, Cable Television Laboratories http://www.opencable.com/specifications/.