W3C

SVG Mobile Requirements

W3C Working Draft 3 August 2001

This version:
http://www.w3.org/TR/2001/WD-SVGMobileReqs-20010803.html
Latest version:
http://www.w3.org/TR/SVGMobileReqs
Editors
Rick Graham (BitFlash) <rick@bitflash.com>
Tolga Capin (Nokia) <Tolga.Capin@nokia.com>

Abstract

This document lists the design principles and requirements for the creation of a mobile profile of the SVG specification to be developed by the W3C SVG2 working group.

Status of this Document

This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by the W3C membership.

This document was developed by the Scalable Vector Graphics (SVG) working group as part of the W3C Graphics Activity. The authors of this document are the SVG Working Group members.

A list of current W3C Recommendations and other technical documents, including Working Drafts and Notes, can be found at http://www.w3.org/TR/.

Feedback on this document should be sent to the email list www-svg2-comments@w3.org. This is a public list that is archived. Public discussion of issues related to vector graphics on the Web and SVG in particular takes place on the public mailing list of the SVG Working Group (list archives). To subscribe send an email to www-svg-request@w3.org with the word subscribe in the subject line.

This section represents the status of this document at the time this version was published. It will become outdated if and when a new version is published. The latest status is maintained at the W3C.

Table of Contents

1. Introduction

The SVG 1.0 specification [SVG 1.0] is now a proposed recommendation.

There is one area that has been identified as lacking in the SVG 1.0 Specification. It has been established by industry demand, overwhelming support in the SVG working group and requests from the SVG developer community that some form of SVG suited to displaying vector graphics on small devices is required. Moreover, the mission statement of SVG 1.0 specifically addresses small devices as a target area for vector graphics display.

In order to meet these demands the SVG2 working group has committed to a concerted effort to create a profile specification that addresses this problem in a timely fashion.

2. Terminology

The following key words and phrases used throughout this document are defined here for clarity. The terms Must, Should, and May are used to specify the extent to which an item is a requirement for the SVG working group in defining mobile profiles for SVG. These recommendations should not be mistaken as a guide to implementors.

  1. 'Must' means that the item is an absolute requirement.
  2. 'Should' means that there may exist valid reasons in particular circumstances to ignore the item, but the full implications must be understood and carefully weighed before choosing a different course.
  3. 'May' means that item will be considered, but further examination is needed to determine if the item should be treated as a requirement.
  4. 'PDA' is a personal data assistant and refers to devices of that family of mobile device.
  5. 'Mobile device' refers to all manner of mobile devices that may be a candidate platform for an SVG agent. Mobile devices would include, but not be restricted to, PDAs and mobile phones.
  6. 'SVG' refers to SVG in general without reference to any version or profile.
  7. 'SVG 1.0' refers to the original SVG specification.
  8. 'SVG 1.1' refers to the version of SVG to be created that is a supreset of SVG 1.0 that has been modularized to allow for easy generation of the SVGB and SVGT profiles.
  9. 'SVG 2.0' refers to the final version of SVG to be produced as defined by the current charter.
  10. 'SVGB' refers to SVG-Basic, a mid level SVG profile for somewhat restricted mobile devices.
  11. 'SVGT' refers to SVG-Tiny, a low level SVG profile for very restricted mobile devices.
  12. 'Mobile SVG' is used to refer to both SVGB and SVGT.
  13. 'Rendering model' refers to the painters model of SVG defined in the SVG 1.0 specification.

3. Usage Scenarios

The following usage scenarios illustrate some of the ways in which mobile SVG profiles might be used for various applications. They may be used as design cases during the development of mobile SVG profiles, and should be useful in helping non-members of the SVG Working Group to understand the intent and goals of this task.

Whatever the task delegated to SVG on small devices, the result will be reliable, scalable viewing of SVG documents and drawings anywhere.

Location-Based Services. Location-based services will be a default service in future systems. With location-based information and applications, mobile subscribers can access a wide range of services, such as traffic and weather reports, restaurant, theatre or movie ticket bookings. Interactive maps, representing points of interest, will be an important part of these services.

Mapping and Positioning. GPS Transceivers make sense on mobile devices, SVG is a vector graphics format perfect for mapping. SVG and Positioning will be a powerful combination on mobile devices.

Animated Picture Messaging. Messaging is a popular service on cellular phones, which lets mobile phone users send and receive ring tones, picture messages, operator logos, business cards, calendar requests, Internet settings, etc., over wireless messaging transports.

Multimedia Messaging. Multimedia Messaging is a continuation of SMS and Picture Messaging. MMS will let users exchange messages with rich content types including natural images, voice clips, video clips, and animated, interactive graphics.

Entertainment. Interactive applications, such as games, cartoon animations, can be developed using mobile SVG profiles.

Industrial Applications. Field engineers locating and dealing with time critical construction and maintenance problems will be able to view maps and engineering plans in the field, on demand.

eCommerce. Graphical views of stock data available on mobile devices will allow day traders to leave their desks, receive intelligent stock data and trade online, on the go.

User Interfaces. SVG markup used to define look and feel for user interface controls will be used to allow vendors and users to add flexibility and accessibility to mobile device graphical user interfaces.

4. Design Principles

  1. It is recognized that some of the goals might conflict or be unachievable and that tradeoffs will have to be made.
  2. Two profiles must be designed to allow SVG to render on mobile devices with limited memory, CPU power, and bandwidth.
  3. Changes to SVG that do not contribute to (4.1) above will be resisted.
  4. Mobile SVG profiles should attempt to maximize compatibility with SVG 1.0 to display existing content.
  5. Extensions to SVG 1.0 will be allowed to support small device functionality. The results of these extensions will be SVG 1.1
  6. There will be resistance to changes that make it difficult for vendors to alter their existing SVG applications.
  7. There will be consideration for the items listed in the SVG 1.1/2.0 Requirements Document [SVG 1.1/2.0 Requirements].
  8. A true subset of the SVG 1.0 imaging model must be maintained.
  9. Mobile SVG should be designed to facilitate authoring tools.
  10. Mobile SVG should be designed so that SVG 1.1 can be transcoded into SVGB and SVGT preserving as much scalability as possible.
  11. We don't believe that a single profile is sufficient to deal with the variety of mobile devices. There will be two profiles, one low level (SVGT) for restricted mobile devices, one for higher level mobile devices (SVGB).

5. Requirements

  1. General Requirements
    1. The profiles must be international.
    2. The rendering model of Mobile SVG must be a true subset of the SVG 1.1 rendering model.
    3. Mobile SVG must consider constraints of handheld devices, particularly low-power CPU, small displays, limited interaction, low bandwidth and small memory.
    4. Mobile SVG must be a true subset of SVG 1.1, and use the appropriate modules from SVG 1.1.
    5. SVGT must be a true subset of SVGB.
    6. Conformance criteria for Mobile SVG must be produced. The criteria should be separated into sections relevant to particular application types (eg. Mobile SVG files/document fragments, Mobile SVG generators, Mobile SVG Viewers, etc)
    7. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type.
    8. A conformance test suite must be developed for both profiles of Mobile SVG. The test suite must be made publicly available. Conformance test suites for other uses of Mobile SVG (e.g. Accessibility guidelines) may be developed.
    9. The SVG conformance test suite must be a superset of the SVGB conformance test suite.
    10. The SVGB conformance test suite must be a superset of the SVGT conformance test suite.
    11. Behaviour must be specified to define how lower level compliant agents will deal with content defined by higher level profiles.
      1. When an SVGT agent is presented with:
        1. SVGB
        2. SVG 1.1
      2. When an SVGB agent is presented with SVG 1.1.
  2. Supported Attribute Types
    1. SVGB profile should support 15.15 fixed point numbers.
    2. SVGT profile may support 15.15 fixed point numbers.
  3. Rendering Model
    1. Mobile SVG has the same rendering model as SVG 1.1 but some language features may be restricted to address implementation constraints.
  4. Document Structure
    1. SVGB should support a large subset of use, image, and symbol.
    2. SVGT may support a subset of use, and symbol.
    3. SVGT should support raster formats and may support the SVG format on the image element.
    4. Mobile SVG must support a subset of the switch element.
  5. References and the 'defs' Element
    1. Mobile SVG must support hyperlinking targets using the 'a' element.
    2. All other referenced objects may be internal.
    3. There may be restrictions on the use of the defs element.
  6. Styling
    1. Mobile SVG must support a subset of SVG 1.1 presentation attributes.
    2. Mobile SVG may allow styling using CSS.
  7. Coordinate Systems, Transformations and Units
    1. SVGB must support viewports.
    2. SVGT should support viewports.
    3. SVGB must support nesting of transformations.
    4. SVGT should support nesting of transformations.
    5. SVGB should support css unit types.
    6. SVGT lengths may be restricted to values in user space. except for width and height attributes on the outermost svg element.
  8. Paths
    1. SVGB must support paths which can be filled and stroked.
    2. SVGT must support paths which can be filled.
    3. SVGT should support paths which can be stroked.
    4. Mobile SVG must support segment types of move, close, line, cubic and quadratic Bézier curves.
    5. Mobile SVG may support segment type elliptical curve.
  9. Basic Shapes
    1. Mobile SVG must support basic shapes (rectangles, circles, ellipses, lines, polylines, and polygons).
  10. Text
    1. Mobile SVG must support international text. It is recognized that full support for international text may not be possible on small devices because of the complexity involved.
    2. SVGB should support text on a path.
    3. SVGT may support text on a path.
    4. SVGB must support a subset of tspan.
    5. SVGT may support a subset of tspan.
  11. Filling, Stroking, and Markers
    1. Mobile SVG must support filling of paths and basic shapes with solid colors.
    2. SVGB must support stroke and stroke-width on paths and basic shapes.
    3. SVGB should support dashed stroke, line joins and end caps.
    4. SVGT may support stroke-width, dashed stroke, line joins and end caps.
    5. SVGB should support stroked text where possible.
    6. SVGB should support a subset of the marker feature set.
    7. SVGT may support a subset of the marker feature set.
  12. Color
    1. Mobile SVG must support colors defined by 'color' property in sRGB color space.
    2. Mobile SVG should support color keywords.
  13. Gradients and Patterns
    1. SVGB should support gradients and patterns.
    2. SVGT may support a subset of gradients and patterns.
  14. Clipping, Masking and Compositing
    1. SVGB should support clipping and masking, and compositing.
    2. SVGB may not support additive clipping.
    3. SVGT may support clipping, masking, and compositing.
  15. Filter Effects
    1. Mobile SVG may support a subset of filter effects.
  16. Interactivity
    1. SVGB must support a large subset of the SVG 1.1 interactivity feature set.
    2. SVGT must support a restricted subset of the SVG 1.1 interactivity feature set.
  17. Linking
    1. SVGB should support a subset of the ability of SVG 1.0 to hyperlink into particular views of SVG content.
    2. SVGT may support a subset of the ability of SVG 1.0 to hyperlink into particular views of SVG content.
    3. SVGB must support hyperlink activation from SVG content to other Web resources.
    4. SVGT should support hyperlink activation from SVG content to other Web resources.
  18. Scripting
    It is recognized that the the developer community considers scripting to be a powerful enabling device in SVG. Scripting engines have large footprints however, and may be difficult to provide on small devices. Scripting will be given careful consideration.
    1. SVGB should support the SVG 1.1 scripting feature set.
    2. SVGT may support the SVG 1.1 scripting feature set.
  19. Animation
    1. SVGB must support a large subset of the animation elements and attributes from SVG 1.1.
    2. SVGT must support a restricted subset of the animation elements and attributes from SVG 1.1.
    3. The list of animatable elements, attributes and properties in Mobile SVG should be those elements, attributes and properties available in the given profile, animatable as defined in the SVG 1.1 specification.
  20. Fonts
    1. Mobile SVG should support built-in system fonts.
    2. SVGB must support SVG fonts with glyph outlines expressed using the "d" attribute on the <glyph> element
    3. SVGT may support SVG fonts with glyph outlines expressed using the "d" attribute on the <glyph> element
    4. Mobile SVG may support SVG fonts with arbitrary SVG glyph content.
  21. Metadata and Extensibility
    1. Mobile SVG must support embedded metadata.
    2. Mobile SVG must allow inclusion of elements and attributes from foreign namespaces within the SVG content.
  22. SVG 1.1/2.0 Extensions Under Consideration
    1. Mobile SVG may include items proposed in the SVG 1.1/2.0 Requirements Document [SVG 1.1/2.0 Requirements].

6. References

SVG 1.0
Scalable Vector Graphics (SVG) 1.0 Specification, Jon Ferraiolo, editor, W3C, 19 July 2001 (Proposed Recommendation). See http://www.w3.org/TR/2001/PR-SVG-20010719/
SVG 1.1/2.0 Requirements
SVG 1.1/2.0 Requirements Document, Dean Jackson, editor, W3C, 3 August 2001. See http://www.w3.org/TR/SVG2Reqs