ghopp
/
server_playground
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Another abandoned server code base... this is kind of an ancestor of taskrambler.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
165 Commits
1 Branch
0 Tags
51 MiB
 
 
 
 
 
 
Tree: 9e1e4f7891
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9e1e4f7891'
${ noResults }
server_playground/doc/www.w3.org/TR/2002/WD-SVG2Reqs-20020422/index.html

1233 lines
50 KiB
Raw Blame History

<!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>