index.html 49.6 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <!-- SVG2 Requirements Document -->
  <!-- $Id: index.html,v 1.4 2002/04/22 12:51:25 dean Exp $ -->

  <head>
    <meta name="generator" content="HTML Tidy, see www.w3.org" />
    <title>SVG 1.1/1.2/2.0 Requirements</title>
<style type="text/css">

      .designgoals {
        list-style-type: decimal;
      }

      .req-level1 {
        list-style-type: decimal;
        font-weight: bold;
      }

      .req-level2 {
        list-style-type: decimal;
        font-weight: normal;
      }

      .req-level1 li {
        margin-top: 1em;
      }

      .req-level2 li {
        margin-top: 0em;
      }

      .label {
        margin-top: 1em;
      }

      .comment {
        background: #ffffaa;
      }

      .svgversion {
        color: #336633;
        font-weight: bold;
      }

      .term {
        font-weight: bold;
        color: #aa3333;
      }


</style>
    <link type="text/css" rel="stylesheet"
    href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
  </head>

  <body>
    <div class="head">
      <p><a href="http://www.w3.org/"
      title="Go to W3C Home Page"><img width="72" height="48"
      alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>

      <h1>SVG 1.1/1.2/2.0 Requirements</h1>

      <h2>W3C Working Draft 22 April 2002</h2>

      <dl>
        <dt>This version:</dt>

        <dd><a
        href="http://www.w3.org/TR/2002/WD-SVG2Reqs-20020422/">
        http://www.w3.org/TR/2002/WD-SVG2Reqs-20020422/</a></dd>

        <dt>Latest version:</dt>

        <dd><a href="http://www.w3.org/TR/SVG2Reqs">
        http://www.w3.org/TR/SVG2Reqs</a></dd>

        <dt>Previous version:</dt>

        <dd><a
        href="http://www.w3.org/TR/2001/WD-SVG2Reqs-20010803.html">
        http://www.w3.org/TR/2001/WD-SVG2Reqs-20010803.html</a></dd>

        <dt>Editor:</dt>

        <dd>Dean Jackson (W3C/CSIRO) <a href="mailto:dean@w3.org">
        &lt;dean@w3.org&gt;</a></dd>
      </dl>

      <p class="copyright"><a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
      Copyright</a> &copy;2002 <a href="http://www.w3.org/"><abbr
      title="World Wide Web Consortium">
      W3C</abbr></a><sup>&reg;</sup> (<a
      href="http://www.lcs.mit.edu/"><abbr
      title="Massachusetts Institute of Technology">MIT</abbr></a>,
      <a href="http://www.inria.fr/"><abbr xml:lang="fr" lang="fr"
      title="Institut National de Recherche en Informatique et Automatique">
      INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved. W3C <a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
      liability</a>, <a
      href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
      trademark</a>, <a
      href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
      document use</a> and <a
      href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
      software licensing</a> rules apply.</p>
    </div>
    <hr />

    <h2><a id="abstract" name="abstract"></a>Abstract</h2>

    <p>This document lists the design principles and requirements
    for future versions of the SVG language, in particular versions
    1.1, 1.2 and 2.0, to be developed by the W3C SVG working group.
    Refer to SVG 1.0 <a href="#ref-svg">[SVG 1.0]</a> for details
    on the current W3C Recommendation.</p>

    <h2><a id="status" name="status"></a>Status of this
    Document</h2>

    <p>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 <a
    href="http://www.w3.org/Consortium/Member/List">W3C
    membership</a>.</p>

    <p>This document was developed by the <a
    href="http://www.w3.org/Graphics/SVG/">Scalable Vector
    Graphics</a> (SVG) working group as part of the W3C <a
    href="http://www.w3.org/Graphics/Activity">Graphics
    Activity</a>. The authors of this document are the SVG Working
    Group members.</p>

    <p>A list of current W3C Recommendations and other technical
    documents, including Working Drafts and Notes, can be found at
    <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>

    <p>Feedback on this document should be sent to the email list
    <a href="mailto:www-svg@w3.org">www-svg@w3.org</a>. This is a
    public list that is <a
    href="http://lists.w3.org/Archives/Public/www-svg/">
    archived</a> and also serves as the public discussion forum for
    issues related to vector graphics on the Web. To subscribe send
    an email to <code>www-svg-request@w3.org</code> with the word
    <code>subscribe</code> in the subject line. Note that only
    subscribers can post to the list.</p>

    <p><em>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.</em></p>

    <h2><a id="contents" name="contents"></a>Table of Contents</h2>

    <ul>
      <li>1. <a href="#sec-intro">Introduction</a></li>

      <li>
        2. <a href="#sec-design">Design Principles</a>

        <ul>
          <li>2.1. <a href="#design-specification">Open
          Specification</a></li>

          <li>2.2. <a href="#design-compatability">Compatible,
          Consistent and Extensible</a></li>

          <li>2.3. <a href="#design-relationship">Relationship to
          other Web formats</a></li>

          <li>2.4. <a href="#design-graphics">Graphics
          Features</a></li>

          <li>2.5. <a href="#design-accessible">Accessible and
          International</a></li>
        </ul>
      </li>

      <li>3. <a href="#sec-terminology">Terminology</a></li>

      <li>
        4. <a href="#sec-requirements">Detailed Requirements</a>

        <ul>
          <li>4.1. <a href="#req-general">General
          Requirements</a></li>

          <li>4.2. <a href="#req-graphics">Graphical
          Features</a></li>

          <li>4.3. <a href="#req-interactivity">
          Interactivity</a></li>

          <li>4.4. <a href="#req-misc">Miscellaneous</a></li>
        </ul>
      </li>

      <li>5. <a href="#sec-references">References</a></li>
    </ul>
    <hr />

    <h2><a id="sec-intro" name="sec-intro"></a>1. Introduction</h2>

    <p>The SVG 1.0 specification <a href="#ref-svg">[SVG 1.0]</a>
    is a Recommendation of the W3C. SVG is a language for defining
    2D graphics that uses XML syntax to describe graphical elements
    that may be rendered in a resolution independent manner. The
    specification defines the visual representation of the
    elements, which can be used in a stand-alone SVG file or
    included in another XML document within the SVG namespace.</p>

    <p>The SVG 1.0 specification is widely implemented by viewing
    and authoring tools on desktop machines. Many server-side
    generation tools dynamically produce SVG content. There is an
    SVG 1.0 Test Suite <a href="#ref-svgtest">[SVG Test Suite]</a>,
    which examines every area of the SVG 1.0 Specification and
    promotes the consistent rendering of SVG content across
    implementations and platforms.</p>

    <p>The next step in the SVG process is developing the
    specifications for future versions of the SVG language, as well
    as profiles of SVG that target particular application areas.
    This document addresses the requirements of three
    specifications, SVG 1.1, SVG 1.2 and SVG 2.0. SVG 1.1 is a
    modularized version of SVG 1.0, including errata from SVG 1.0
    and the minumum number of new features needed to develop an SVG
    profile for mobile devices <a href="#ref-svgmobilereqs">[SVG
    Mobile Requirements]</a> <a href="#ref-svgmobile">[SVG Mobile
    Profiles]</a>. SVG 1.2 is a "dot-release" increment to the SVG
    1.1 language, adding the most needed and most requested new
    features to SVG without being a major revision. SVG 2.0 will
    include the additional SVG 1.1 and SVG 1.2 features, and other
    new features of value to the SVG community. Parallel to the
    development of these versions of SVG, the SVG Working Group
    will develop a number of profiles for SVG (e.g. full SVG, SVG
    Tiny and SVG Basic for mobile or resource-limited devices and
    an SVG Printing profile). This document describes the
    requirements for the 1.1, 1.2 and 2.0 versions of the SVG
    Specification, with labels suggesting which version of the
    specification may meet the requirement.</p>

    <p>Drafts of SVG 1.1 are already available <a
    href="#ref-svg11">[SVG 1.1]</a>. A first draft of the future
    SVG 1.2 specification is expected within a month of this
    requirements document being posted for public review. A first
    draft of SVG 2.0 is expected before the end of 2002. All three
    specifications will be developed taking into account:</p>

    <ul>
      <li>the design goals, detailed requirements and candidate
      features described in this document</li>

      <li>feedback on this document from the public, invited
      experts and SVG Working Group members (see the Status section
      for feedback instructions).</li>
    </ul>

    <h2><a id="sec-design" name="sec-design"></a>2. Design
    Principles</h2>

    <p>The following design principles will be considered for SVG
    1.1/1.2/2.0. These principles complement the list in the SVG
    1.0 requirements document <a href="#ref-svgreqs">[SVG 1.0
    Requirements]</a>.</p>

    <h3><a id="design-specification" name="design-specification">
    </a>2.1. General</h3>

    <ol class="designgoals">
      <li>SVG 1.1/1.2/2.0 should be targeted as a standard feature
      on desktops (web browsers, graphical applications, authoring
      tools, file interchange), mobile and small devices (browsers,
      user interfaces, automotive systems), printers and industrial
      applications.</li>

      <li>SVG should be able to describe the common and extended
      feature set of today's graphical authoring environments, both
      tools and programs. SVG should be a common export format in
      these applications.</li>

      <li>It must be possible to define a profile (subset of SVG)
      that can be implemented on devices with resource constraints.
      For example, a mobile device may not have the display
      resolution or processing power for all SVG elements, and it
      should be possible to create content that can be viewed on
      such a device.</li>

      <li>New features in the specification should be accompanied
      by a comprehensive test suite exercising the feature. An
      essential requirement in the W3C process is the demonstration
      that all features in a specification can be implemented.
      Therefore, implementation feedback will play a large part in
      the specification's design.</li>
    </ol>

    <h3><a id="design-compatability" name="design-compatability">
    </a>2.2. Compatible, Consistent and Extensible</h3>

    <ol class="designgoals">
      <li>SVG 1.1/1.2/2.0 must be as compatible as possible with
      the SVG 1.0 specification.</li>

      <li>All elements and attributes should be consistent within
      SVG, and with external specifications such as CSS and XSL.
      This includes the naming of elements, the set of available
      attributes and the style properties that can be used on
      elements.</li>

      <li>The SVG 1.1/1.2/2.0 specifications must be modular to
      allow profiling.</li>
    </ol>

    <h3><a id="design-relationship" name="design-relationship">
    </a>2.3. Relationship to other Web formats</h3>

    <ol class="designgoals">
      <li>New features are expressed in XML or related technologies
      (e.g. style properties are compatible with CSS).</li>

      <li>
        Compatible with and/or leverages other relevant standards
        efforts, including XML namespaces, XForms, DOM3, CSS3 and
        metadata. For example:

        <ul>
          <li>SVG elements and attributes should be accessible via
          the DOM, and if useful, the SVG DOM.</li>

          <li>SVG elements should raise appropriate XML Events as
          needed</li>

          <li>SVG should be compatible with XForms User Interface
          presentation</li>

          <li>SVG should review developments from other working
          groups and examine how those features could be
          integrated.</li>

          <li>SVG should support metadata that can be used in a
          semantic web context</li>
        </ul>
      </li>

      <li>Should be possible to easily embed other XML content
      within SVG, and to embed SVG into other XML content. This may
      require special attention in terms of event propagation and
      styling properties that will require liaison with other W3C
      groups.</li>
    </ol>

    <h3><a id="design-graphics" name="design-graphics"></a>2.4.
    Graphics Features</h3>

    <ol class="designgoals">
      <li>Complete, general-purpose Web graphics format that meets
      the graphics needs of all creators and consumers of Web
      content.</li>

      <li>Sufficiently powerful and precise to meet the needs of
      professional Web designers such that they will utilize SVG
      instead of raster formats in those cases where vector
      graphics is a more natural or appropriate format.</li>

      <li>Sufficiently powerful to meet the needs of business
      presentation and diagramming applications such that these
      drawings will be published on the Web using SVG instead of
      raster formats.</li>

      <li>Sufficiently compatible with the graphics design and
      publishing industries' feature sets and file formats such
      that there is (as lossless as possible) a straightforward
      mapping from these applications and file formats into SVG.
      The goals are to facilitate conversion of existing artwork
      into SVG, promote the creation of lots of compelling new SVG
      artwork, make it as easy as possible for the graphics design
      and publishing industries to adapt existing authoring tools,
      and provide for new SVG authoring tools.</li>

      <li>Feature set is complete enough to provide a reasonable
      conversion from existing graphics formats (vector and
      raster).</li>

      <li>To allow or include relevant enhancements from target
      domains such as GIS/Mapping, CAD/Design, Mobile, Printing and
      Web Design. Enhancements that are useful in the general case
      may be added to SVG, while domain-specific enhancements may
      require the examination of SVG interoperability with another
      XML grammar.</li>

      <li>Should investigate unification of existing style elements
      so there is a common model for existing and future rendering
      elements.</li>

      <li>Should be compatible with the current standard imaging
      model for graphics.</li>

      <li>Should be able to function as an application's user
      interface.</li>
    </ol>

    <h3><a id="design-accessible" name="design-accessible"></a>2.5.
    Accessible and International</h3>

    <ol class="designgoals">
      <li>SVG content should be able to conform to the W3C Web
      Accessibility Initiative Content Guidelines.</li>

      <li>SVG user agents should be able to conform to the W3C Web
      Accessibility Initiative User Agent Guidelines. In
      conjunction with the UA Working Group, the SVG Working Group
      will specify how the User Agent Accessibility Guidelines
      apply to SVG 1.1/1.2/2.0.</li>

      <li>All features in SVG should be available to the
      international community.</li>
    </ol>

    <h2><a id="sec-terminology" name="sec-terminology"></a>3.
    Terminology</h2>

    <p>The key words "<span class="term">must</span>", "<span
    class="term">should</span>" and "<span class="term">may</span>"
    are to be interpreted in the detailed requirements as
    follows:</p>

    <dl>
      <dt><span class="term">must</span></dt>

      <dd>The item is an absolute requirement of the
      specification.</dd>

      <dt><span class="term">should</span></dt>

      <dd>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.</dd>

      <dt><span class="term">may</span></dt>

      <dd>The item will be considered, but further examination is
      needed to determine if the item should be treated as a
      requirement.</dd>
    </dl>

    <p>Note that only the highlighted versions of the terms are to
    be interpreted as above. Terms that are not highlighted should
    be interpreted as usual.</p>

    <h2><a id="sec-requirements" name="sec-requirements"></a>4.
    Detailed Requirements</h2>

    <p>The following is the detailed list of required features in
    SVG 1.1/1.2/2.0. It is recognized that some of these
    requirements may conflict or may not be possible.</p>

    <h3><a id="req-general" name="req-general"></a>4.1. General
    Requirements</h3>

    <ol class="req-level1">
      <li>
        <a id="req-compatibility" name="req-compatibility">
        </a>Compatibility

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> be backwards
          compatible. That is, no modification to SVG should cause
          SVG content conforming to a particular version to be
          rendered differently in viewers that conform to any
          higher version of the SVG specification. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG 1.1/1.2/2.0 <span class="term">should</span> use
          the same syntax as SVG 1.0 (i.e. any new elements <span
          class="term">should</span> be consistent with SVG 1.0).
          <span class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>New attributes (or attribute values) on SVG 1.0
          elements <span class="term">should</span> produce the
          same default behavior as SVG 1.0 wherever possible. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>The rendering model of SVG 1.1/1.2/2.0 <span
          class="term">may</span> not be identical to SVG 1.0.
          However, the SVG 1.0 rendering model <span class="term">
          should</span> be the default. <span class="svgversion">
          [SVG 1.1]</span> <span class="svgversion">[SVG
          1.2]</span> <span class="svgversion">[SVG
          2.0]</span></li>

          <li>Ideally, updates and major revisions to the SVG 1.0
          language <span class="term">should</span> be accompanied
          by XSLT transformation scripts to assist in updating
          legacy content. <span class="svgversion">[SVG 1.1]</span>
          <span class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-modularization" name="req-modularization">
        </a>Modularization and Profiling

        <ol class="req-level2">
          <li>The SVG 1.0 language <span class="term">must</span>
          be modularized into an SVG 1.1 specification. <span
          class="svgversion">[SVG 1.1]</span></li>

          <li>Profiles for SVG <span class="term">must</span>
          describe the SVG modules that they implement, as well as
          any additional information relative to the profile. <span
          class="svgversion">[SVG 1.1]</span></li>

          <li>There <span class="term">must</span> be one or more
          profiles for mobile devices with resource constraints.
          <span class="svgversion">[SVG 1.1]</span></li>

          <li>There <span class="term">may</span> be profiles for
          other resource-limited devices. <span class="svgversion">
          [SVG 1.2]</span></li>

          <li>There <span class="term">should</span> be profiles
          for printers. <span class="svgversion">[SVG
          1.2]</span></li>

          <li>There <span class="term">may</span> be a combined
          SVG+SMIL profile, describing how SVG 1.1/1.2 content can
          be integrated with SMIL 2.0 modules. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-conformance" name="req-conformance">
        </a>Conformance

        <ol class="req-level2">
          <li>Conformance criteria for the SVG specifications and
          profiles <span class="term">must</span> be produced. The
          criteria <span class="term">should</span> be separated
          into sections relevant to particular application types
          (e.g. SVG generators, SVG files, SVG Mobile Viewers, etc)
          <span class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>Software or documents <span class="term">must</span>
          pass the relevant criteria to be able to claim
          conformance to the particular application type. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>A test suite <span class="term">must</span> be
          developed for each specification and profile. The test
          suite <span class="term">must</span> be made publicly
          available. Test suites for other uses of SVG (e.g.
          Accessibility Requirements) <span class="term">may</span>
          be developed. <span class="svgversion">[SVG 1.1]</span>
          <span class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>The specification <span class="term">should</span>
          contain a section on authoring guidelines, which may
          include or refer to descriptions of methods for
          generating accessible content, guidelines for authoring
          tools and tips for content generation (server-side,
          hand-coding, etc). <span class="svgversion">[SVG
          1.1]</span> <span class="svgversion">[SVG 1.2]</span>
          <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>
    </ol>

    <h3><a id="req-graphics" name="req-graphics"></a>4.2 Graphical
    Features</h3>

    <ol class="req-level1">
      <li>
        <a id="req-shapes" name="req-shapes"></a>Shapes and Paths

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> extend the current
          set of predefined basic shapes, or add attributes to
          existing basic shapes to increase functionality. The
          predefined shapes are included to assist in the manual
          generation of SVG content, as well as to provide an
          efficient means in which to store common shapes. The set
          of new basic shape elements <span class="term">may</span>
          include an arc (open, closed, pie slice), a spiral, star
          and regular polygons. The set of new attributes on
          existing shapes <span class="term">may</span> include a
          rotation angle on the ellipse element. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>The range of path segment types <span class="term">
          should</span> be examined. New segment types <span
          class="term">may</span> be added. As in SVG 1.0, the path
          syntax <span class="term">should</span> be efficient in
          both size and processing. <span class="svgversion">[SVG
          2.0]</span></li>

          <li>The set of new segments <span class="term">may</span>
          include general splines, mathematical functions, or a
          reference to another path element (allowing shared
          borders on elements). Path segments <span class="term">
          may</span> also allow defined points (providing common
          vertices for path elements). Path data may be extended to
          support constraint features <span class="svgversion">[SVG
          2.0]</span></li>

          <li>The syntax for path data <span class="term">
          may</span> be enhanced to provide aliases for segment
          identifiers that are potentially confusing. For example
          the relative "lineto" segment is defined using a
          lowercase "L" which can be mistaken for the number "1".
          The alias "r" (lowercase "R") <span class="term">
          may</span> be allowed for relative lineto. <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> define points and
          allow shape elements and paths to reference them. This
          would facilitate connection points on elements. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> define a set of
          predefined user interface controls, such as those needed
          for form interaction (e.g. buttons, text fields, sliders,
          etc). Many images on the web today are raster versions of
          "web buttons" which could be more efficiently expressed
          in SVG. This requirement will involve liason with the
          XForms Working Group <span class="svgversion">[SVG
          1.2]</span> <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-text" name="req-text"></a>Text

        <ol class="req-level2">
          <li>SVG 1.2 <span class="term">should</span> allow word
          wrapping and forced line breaks for text within multiple
          rectangles <span class="svgversion">[SVG 1.2]</span></li>

          <li>SVG 2.0 <span class="term">should</span> allow word
          wrapping, forced line breaks and text flow within
          multiple shapes <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG text <span class="term">should</span> allow
          justification locations, such as the nine standard
          positions (bottom, center, top with left, middle, right).
          Note that this requirement will involve coordination with
          the CSS and XSL groups, and investigation by the
          Internationalization group. <span class="svgversion">[SVG
          1.2]</span> <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG <span class="term">may</span> allow text to be
          justified flush within a shape. <span class="svgversion">
          [SVG 2.0]</span></li>

          <li>The transform attribute <span class="term">
          should</span> be added to the tspan element <span
          class="svgversion">[SVG 1.2]</span></li>

          <li>SVG <span class="term">should</span> provide a method
          to define how whitespace is handled. SVG <span
          class="term">may</span> provide an attribute that defines
          how a text element should handle whitespace, overriding
          the use of the xml:space attribute. <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-images" name="req-images"></a>Images

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> examine the
          JPEG2000 specification for relevant features. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> require support for
          JPEG2000 images. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-color" name="req-color"></a>Color

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> define a color
          element that can be referenced as a paint server in the
          same manner that is currently used for gradients and
          patterns. The color element <span class="term">
          should</span> be able to specify the opacity of the
          color. <span class="svgversion">[SVG 1.2]</span></li>

          <li>Furthermore, SVG <span class="term">should</span>
          require all potential new paint servers to be defined in
          a separate element that can be referenced by the style
          properties. <span class="svgversion">[SVG 1.1]</span>
          <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">should</span> extend the list
          of color representation spaces that are accessible within
          a document. Potential color spaces are CMYK and PANTONE.
          <span class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> allow a palette of
          colors or other paint styles to be defined, with the
          style properties that can reference paint servers able to
          use this palette as an indexed color table. SVG <span
          class="term">may</span> also allow a set of alternative
          palettes to be described, with the most suitable palette
          for the output device chosen at rendering time. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-compositing" name="req-compositing">
        </a>Compositing

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> allow for a
          broader range of compositing operations in the rendering
          model. Potential compositing operations are the modes
          from the SVG 1.0 feComposite (in, over, out, atop, xor
          and arithmetic) and feBlend (multiply, screen, darken,
          lighten) elements, as well as the collection of blending
          modes available in PDF 1.4 (overlay, soft light, hard
          light, color dodge, color burn, difference, exclusion).
          SVG <span class="term">should</span> attempt to preserve
          a default painter's rendering model. <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-coords" name="req-coords"></a>Coordinates and
        Transformations

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> allow elements
          to be defined in the coordinate system used by the view
          port. SVG 1.0 only allows elements to be defined in the
          user coordinate system, ensuring they are always affected
          by the current user space to view port transformation.
          Many applications, such as user interfaces, require
          objects that are not affected by the user space
          transformation, i.e. their position and size remain
          constant. Examples of such applications are the legend on
          a chart, symbols on a map and buttons in a user
          interface. <span class="svgversion">[SVG 1.2]</span>
          <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> allow
          transformations to allow higher level matrices and
          perspective transformations. The validity and extent of
          this feature will require implementation feedback. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">should</span> allow the
          document to use a Y-up coordinate system. Elements that
          define text rendering <span class="term">should</span>
          continue to use a Y-up coordinate system. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">should</span> provide a
          mechanism to name the coordinate system used by sections
          of the document. For example, the coordinates used by the
          elements in the SVG file may be defined in the "D/WGS84"
          coordinate system. <span class="svgversion">[SVG
          1.1]</span> <span class="svgversion">[SVG 1.2]</span>
          <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-fill" name="req-fill"></a>Paint Servers

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> include more types
          of gradient elements. Potential gradient elements include
          conical, rectangular, Gouraud shading, triangle mesh,
          Coons patch and shaped fill (with gradient offsets
          determined by the distance from the edge of the shape).
          <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> support the
          winding-counting fill rule (where overlaps are repeatedly
          filled). <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">should</span> support the CSS
          background properties on some elements, particularly the
          outermost SVG element and text elements. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> allow the user to
          control the boundary of the fill. For example, the fill
          could entirely overlap the stroke or remain completely
          within the stroke. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-stroke" name="req-stroke"></a>Stroke Styles

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> support
          definable stroke styles. Possible examples of defined
          styles are wave strokes, strokes with multiple lines and
          the brushes that are supported by many illustration
          packages. <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> support more join
          styles (e.g. chamfer). <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG <span class="term">may</span> allow the order of
          stroking in the rendering process to be controlled (i.e.
          to come before the fill). <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG <span class="term">may</span> allow the user to
          control the location of the stroke. For example, the
          stroke could be centered on the outline, adjacent to the
          outline and outside the shape or adjacent to the outline
          and inside the shape. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-styling" name="req-styling"></a>Styling

        <ol class="req-level2">
          <li>SVG <span class="term">must</span> take into account
          updates to the CSS and XSL specifications. <span
          class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-params" name="req-params"></a>Parameterized
        elements

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> have a mechanism
          to allow parameter substitution on attributes in repeated
          instances of elements, such as symbols. For example, a
          grid-like structure could be constructed by repeating a
          line element with different transformations. <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-contraints" name="req-contraints">
        </a>Constraints

        <ol class="req-level2">
          <li>SVG 1.2 <span class="term">may</span> have a general
          constraint feature that provides flexible layout of
          elements based on relations to other elements or
          attributes. Constraints may affect the size and position
          of elements. SVG <span class="term">may</span> use XPath
          and/or XSLT syntax to declaratively describe the
          constraints. <span class="svgversion">[SVG
          1.2]</span></li>

          <li>SVG 2.0 <span class="term">should</span> have a
          general constraint feature that provides flexible layout
          of elements based on relations to other elements or
          attributes. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-units" name="req-units"></a>Units

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> allow CSS units in
          the polylines, polygons, paths and transforms. However,
          the CSS unit facility <span class="term">may</span> be
          deprecated in favour of an alternative approach using
          constraints. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-grouping" name="req-grouping"></a>Grouping

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> provide a mechanism
          to control rendering order, such as a "z-index"
          attribute. <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> provide the concept
          of layers. <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-vectoreffects" name="req-vectoreffects">
        </a>Vector Effects

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> provide a mechanism
          to apply vector effects to elements in a manner similar
          to the existing raster filter effects. <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>
    </ol>

    <h3><a id="req-interactivity" name="req-interactivity"></a>4.3.
    Interactivity</h3>

    <ol class="req-level1">
      <li>
        <a id="req-selection" name="req-selection"></a>Selection

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> allow the selection
          of multiple elements. <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG 1.2 <span class="term">may</span> allow both text
          and graphical elements to be selected. <span
          class="svgversion">[SVG 1.2]</span></li>

          <li>SVG 2.0 <span class="term">should</span> allow both
          text and graphical elements to be selected. <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-referencing" name="req-referencing">
        </a>Referencing

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> provide a mechanism
          for pointing to a particular state of the document. Where
          the view element describes a region to display, the
          state-based view would describe a geometric region at a
          particular time in the document timeline, or after
          particular events have been triggered on defined
          elements. <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-forms" name="req-forms"></a>Forms

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> coordinate with
          the XForms Working Group. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-animation" name="req-animation"></a>Animation

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> investigate
          alternative approaches to associating animation elements
          with the elements being animated. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> provide greater
          control over the color space used in an animation that
          modifies color (e.g. animateColor in HSV). <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG 1.2 <span class="term">should</span> provide a
          mechanism to support streaming animations. A potential
          solution is to start the document timeline when the
          document loading begins (at the earliest possible point).
          <span class="svgversion">[SVG 1.2]</span></li>

          <li>SVG 2.0 <span class="term">must</span> provide a
          mechanism to support streaming animations. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> allow the speed of
          the document timeline to be controlled, in effect
          speeding up or slowing down the document clock. <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">should</span> allow different
          timelines in the same document. SVG <span class="term">
          may</span> use the syncBehavior attribute from SMIL.
          <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-events" name="req-events"></a>Events

        <ol class="req-level2">
          <li>SVG 1.2 <span class="term">may</span> require DOM
          Level 3 Events. <span class="svgversion">[SVG
          1.2]</span></li>

          <li>SVG 1.2 <span class="term">may</span> incorporate the
          XML event model <a href="#ref-xmlevents">[XML
          Events]</a>, allowing the definition of any DOM event
          listener in markup. <span class="svgversion">[SVG
          1.2]</span></li>

          <li>SVG 2.0 <span class="term">should</span> incorporate
          the XML event model <a href="#ref-xmlevents">[XML
          Events]</a>. <span class="svgversion">[SVG
          2.0]</span></li>

          <li>SVG <span class="term">should</span> provide a
          mechanism to trigger dynamic content based on the level
          of zoom or location of the viewport. SVG <span
          class="term">may</span> also provide a mechanism to
          support a document with elements tagged with level of
          detail information (e.g. maps). <span class="svgversion">
          [SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-scripting" name="req-scripting"></a>Scripting

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> provide a subset
          of scripting facilities in XML markup. SVG <span
          class="term">may</span> introduce an element that handles
          events and modifies the DOM. <span class="svgversion">
          [SVG 2.0]</span></li>
        </ol>
      </li>
    </ol>

    <h3><a id="req-misc" name="req-misc"></a>4.4.
    Miscellaneous</h3>

    <ol class="req-level1">
      <li>
        <a id="req-raster" name="req-raster"></a>General
        Extensibility

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> provide a mechanism
          to allow extensions to the language, in particular
          filters and paint servers. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-codeprotection" name="req-codeprotection">
        </a>Code protection

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> investigate
          mechanisms for hiding SVG code from the user, with
          conforming SVG viewers not allowing the user access to
          the SVG document or DOM. Collaboration with the XML
          Encryption and XML Signature working groups will be
          necessary. <span class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-altcontent" name="req-altcontent">
        </a>Alternative content

        <ol class="req-level2">
          <li>SVG <span class="term">should</span> allow more
          attributes in the tests for the switch element. For
          example, content could switch on device characteristics
          as well as provide alternative content based on the
          version/profile of the specification to which the viewer
          conforms. <span class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> provide a mechanism
          to control the result of a switch element, allowing
          access to alternative content that otherwise would not
          have been available. <span class="svgversion">[SVG
          2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-printing" name="req-printing"></a>Enhanced
        Printing

        <ol class="req-level2">
          <li>SVG <span class="term">may</span> provide a page
          description model, allowing page breaks to be defined in
          SVG content. <span class="svgversion">[SVG 1.2]</span>
          <span class="svgversion">[SVG 2.0]</span></li>

          <li>SVG <span class="term">may</span> provide DOM events
          related to printing, such as an onPrint event. <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>

      <li>
        <a id="req-errors" name="req-errors"></a>Error Processing

        <ol class="req-level2">
          <li>SVG <span class="term">must</span> provide
          comprehensive instructions to user agents when processing
          non compliant SVG content, or content that is not from an
          SVG version or profile that the user agent can handle.
          <span class="svgversion">[SVG 1.1]</span> <span
          class="svgversion">[SVG 1.2]</span> <span
          class="svgversion">[SVG 2.0]</span></li>
        </ol>
      </li>
    </ol>

    <h2><a id="sec-references" name="sec-references">
    </a>References</h2>

    <dl class="references">
      <dt class="label"><a id="ref-svg" name="ref-svg"></a>[SVG
      1.0]</dt>

      <dd><em>Scalable Vector Graphics (SVG) 1.0
      Specification</em>, Jon Ferraiolo, editor, W3C, 4 September
      2001 (Recommendation). See <a
      href="http://www.w3.org/TR/2001/REC-SVG-20010904/">
      http://www.w3.org/TR/2001/REC-SVG-20010904/</a> or the <a
      href="http://www.w3.org/TR/SVG/">Latest Version</a></dd>

      <dt class="label"><a id="ref-svg11" name="ref-svg11"></a>[SVG
      1.1]</dt>

      <dd><em>Scalable Vector Graphics (SVG) 1.1
      Specification</em>, Dean Jackson, editor, W3C, 15 February
      2002 (Last Call Working Draft). See <a
      href="http://www.w3.org/TR/2002/WD-SVG11-20020215/">
      http://www.w3.org/TR/2002/WD-SVG11-20020215/</a> or the <a
      href="http://www.w3.org/TR/SVG11/">Latest Version</a></dd>

      <dt class="label"><a id="ref-svgreqs" name="ref-svgreqs">
      </a>[SVG 1.0 Requirements]</dt>

      <dd><em>SVG 1.0 Requirements Document</em>, Jon Ferraiolo,
      editor, W3C, 29 October 1998 (Working Draft). See <a
      href="http://www.w3.org/TR/WD-SVGReq">
      http://www.w3.org/TR/WD-SVGReq</a></dd>

      <dt class="label"><a id="ref-svgmobile" name="ref-svgmobile">
      </a>[SVG Mobile Profiles]</dt>

      <dd><em>Mobile SVG Profiles: SVG Tiny and SVG Basic</em>,
      Tolga Capin, editor, W3C, 15 February 2002 (Last Call Working
      Draft). See <a
      href="http://www.w3.org/TR/2002/WD-SVGMobile-20020215/">
      http://www.w3.org/TR/2002/WD-SVGMobile-20020215/</a> or the
      <a href="http://www.w3.org/TR/SVGMobile/">Latest
      Version</a></dd>

      <dt class="label"><a id="ref-svgmobilereqs"
      name="ref-svgmobilereqs"></a>[SVG Mobile Requirements]</dt>

      <dd><em>SVG Mobile Requirements Document</em>, Rick Graham,
      Tolga Capin, editors, W3C, 3 August 2001 (Working Draft). See
      <a href="http://www.w3.org/TR/SVGMobileReqs">
      http://www.w3.org/TR/SVGMobileReqs</a> for latest
      version.</dd>

      <dt class="label"><a id="ref-svgtest" name="ref-svgtest">
      </a>[SVG Test Suite]</dt>

      <dd><em>SVG 1.0 Test Suite</em>, See <a
      href="http://www.w3.org/Graphics/SVG/Test/">
      http://www.w3.org/Graphics/SVG/Test/</a></dd>

      <dt class="label"><a id="ref-w3cprocess"
      name="ref-w3cprocess"></a>[W3C Process]</dt>

      <dd><em>W3C Process Document</em>, See <a
      href="http://www.w3.org/Consortium/Process/">
      http://www.w3.org/Consortium/Process/</a> for the latest
      version.</dd>

      <dt class="label"><a id="ref-xmlevents" name="ref-xmlevents">
      </a>[XML Events]</dt>

      <dd><em>XML Events</em>, See <a
      href="http://www.w3.org/TR/2001/WD-xml-events-20011026/">
      http://www.w3.org/TR/2001/WD-xml-events-20011026/</a> or the
      <a href="http://www.w3.org/TR/xml-events/">Latest
      Version</a></dd>
    </dl>
  </body>
</html>