- From: Little, Chris <chris.little@metoffice.gov.uk>
- Date: Tue, 3 Mar 2015 18:53:45 +0000
- To: "Kerry.Taylor@csiro.au" <Kerry.Taylor@csiro.au>, "harth@kit.edu" <harth@kit.edu>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
Kerry, Ed, Andreas, and colleagues,
I have now read the detail and I think that I understand it. The SVG 'feature' allows the user to state in a metadata element, by GML3.2.1 snippet, what CRS was used to construct the graphical image, and any other transformation, such as switching axes, etc. This seems eminently sensible and not too restrictive.
Hence, I think we could ask the SVG group to leave the capability in the SVG2 spec, or at worst, have it as an informative annex.
Of course convincing use cases would help, and web mapping seems persuasive.
Chris
-----Original Message-----
From: Kerry.Taylor@csiro.au [mailto:Kerry.Taylor@csiro.au]
Sent: Wednesday, February 25, 2015 7:49 PM
To: harth@kit.edu; public-sdw-wg@w3.org
Subject: RE: Geospatial decision in W3C SVG WG: Move svg:transform mapping to its own spec
Web mapping is the obvious one -- but it is assertively out of scope!
> -----Original Message-----
> From: Andreas Harth [mailto:harth@kit.edu]
> Sent: Thursday, 26 February 2015 3:52 AM
> To: public-sdw-wg@w3.org
> Subject: Re: Geospatial decision in W3C SVG WG: Move svg:transform
> mapping to its own spec
>
> Hi,
>
> would that be something to write as a use case? If SVG with
> geo is a requirement that can be derived from a use case, we
> would ensure that SVG/geo shows up somewhere. The tricky bit
> is coming up with a use case that would require SVG/geo.
>
> Cheers,
> Andreas.
>
> On 2015-02-24 11:52, Little, Chris wrote:
> > Kerry, Ed,
> >
> > Just checking that you were aware of this activity, and perhaps we
> should ensure SVG with geo info embedded in metadata is included in a
> SDWWG deliverable at some time.
> >
> > Chris
> >
> > -----Original Message-----
> > From: SVG Working Group repository [mailto:cam+svgwgrepo@mcc.id.au]
> > Sent: Friday, February 13, 2015 4:21 AM
> > To: w3c-svg-wg@w3.org
> > Subject: [svgwg] Move svg:transform mapping to its own spec
> >
> >
> https://github.com/w3c/svgwg/commit/637ae4967c0b923a97c5c8f82ac530d4482
> 3d1a3
> > commit 637ae4967c0b923a97c5c8f82ac530d44823d1a3
> > Author: Dirk Schulze <dschulze@chromium.org>
> > Date: Fri Feb 13 15:18:27 2015 +1100
> >
> > Move svg:transform mapping to its own spec
> >
> > diff --git a/master/coords.html b/master/coords.html
> > index ecf00e8..be645c1 100644
> > --- a/master/coords.html
> > +++ b/master/coords.html
> > @@ -1574,44 +1574,6 @@ object within a containing block that is only
> constrained in one direction.</p>
> > <a
> href="https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVk
> HWH9jRVN-w8A4aNsIk/">examples</a>
> > provided by David Vest.</p>
> >
> > -<h2 id="GeographicCoordinates">Geographic coordinate systems</h2>
> > -
> > -<p>In order to allow interoperability between SVG content generators
> > -and user agents dealing with maps encoded in SVG, the use of a
> common
> > -metadata definition for describing the coordinate system used to
> > -generate SVG documents is encouraged.</p>
> > -
> > -<p>Such metadata must be added under the <a>'metadata'</a> element
> of
> > -the topmost <a>'svg'</a> element describing the map, consisting of
> an
> > -RDF description of the Coordinate Reference System definition used
> to
> > -generate the SVG map [<a href='refs.html#ref-RDF-PRIMER'>RDF-
> PRIMER</a>]. Note that
> > -the presence of this metadata does not affect the rendering of the
> SVG
> > -in any way; it merely provides added semantic value for applications
> > -that make use of combined maps.</p>
> > -
> > -<p>The definition must be conformant to the XML grammar described in
> > -<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > -an OpenGIS Standard for encoding common CRS data types in XML
> > -[<a href='refs.html#ref-GML'>GML</a>]. In order to correctly map
> > -the 2-dimensional data used by SVG, the CRS must be of subtype
> > -<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > -first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > -second axis maps the SVG <var>y</var>-axis.</p>
> > -
> > -<p>The main purpose of such metadata is to indicate to the user
> agent
> > -that two or more SVG documents can be overlayed or merged into a
> single
> > -document. Obviously, if two maps reference the same Coordinate
> Reference
> > -System definition and have the same SVG <a>'transform'</a> property
> > -value then they can be overlayed without reprojecting the data. If
> > -the maps reference different Coordinate Reference Systems and/or
> have
> > -different SVG <a>'transform'</a> property values, then a specialized
> > -cartographic user agent may choose to transform the coordinate data
> to
> > -overlay the data. However, typical SVG user agents are not required
> > -to perform these types of transformations, or even recognize the
> > -metadata. It is described in this specification so that the
> connection
> > -between geographic coordinate systems and the SVG coordinate system
> is
> > -clear.</p>
> > -
> > <h2 id="DOMInterfaces">DOM interfaces</h2>
> >
> > <h3 id="InterfaceSVGPointList">Interface SVGPointList</h3>
> > @@ -2052,8 +2014,6 @@ interface <b>SVGTransform</b> {
> > <p>If <var>value</var> could not be parsed as a
> > <a><transform-function></a>, then a <a
> href="http://dvcs.w3.org/hg/domcore/raw-
> file/tip/Overview.html#syntaxerror">SyntaxError</a>
> > is thrown.</p>
> > - <p class='issue'>The CSS Transforms specification does not
> have
> > - a grammar for <a><transform-function></a> yet.</p>
> > </div>
> > </dd>
> > </dl>
> > diff --git a/specs/transform/Overview.bs
> b/specs/transform/Overview.bs
> > new file mode 100644
> > index 0000000..4c1c144
> > --- /dev/null
> > +++ b/specs/transform/Overview.bs
> > @@ -0,0 +1,325 @@
> > +<h1>svg:transform for mapping</h1>
> > +<pre class='metadata'>
> > +Level: 1
> > +Status: ED
> > +ED: http://dev.w3.org/fxtf/motion-1/
> > +Shortname: transform-mapping
> > +Group: svg
> > +Editor: Satoru Takagi, KDDI Corporation, sa-takagi@kddi.com
> > +Abstract: This specification gives guidance how the SVG transform
> attribute in the SVG namespace can be used in other context than SVG.
> > +</pre>
> > +<pre class=link-defaults>
> > +spec:svg2; type:element; text:svg
> > +spec:css-transforms-1; type:property; text:transform
> > +spec:css-transforms-1; type:type; text:<transform-list>
> > +</pre>
> > +
> > +<h2 id="GeographicCoordinates">Geographic coordinate systems</h2>
> > +
> > +In order to allow interoperability between SVG content generators
> > +and user agents dealing with maps encoded in SVG, the use of a
> common
> > +metadata definition for describing the coordinate system used to
> > +generate SVG documents is encouraged.
> > +
> > +Such metadata must be added under the <a element>metadata</a>
> element of
> > +the topmost <a element>svg</a> element describing the map,
> consisting of an
> > +RDF description of the Coordinate Reference System definition used
> to
> > +generate the SVG map [[RDF-PRIMER]]. Note that
> > +the presence of this metadata does not affect the rendering of the
> SVG
> > +in any way; it merely provides added semantic value for applications
> > +that make use of combined maps.
> > +
> > +The definition must be conformant to the XML grammar described in
> > +<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > +an OpenGIS Standard for encoding common CRS data types in XML
> > +[<a href='refs.html#ref-GML'>GML</a>]. In order to correctly map
> > +the 2-dimensional data used by SVG, the CRS must be of subtype
> > +<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > +first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > +second axis maps the SVG <var>y</var>-axis.
> > +
> > +The main purpose of such metadata is to indicate to the user agent
> > +that two or more SVG documents can be overlayed or merged into a
> single
> > +document. Obviously, if two maps reference the same Coordinate
> Reference
> > +System definition and have the same SVG 'transform' property
> > +value then they can be overlayed without reprojecting the data. If
> > +the maps reference different Coordinate Reference Systems and/or
> have
> > +different SVG 'transform' property values, then a specialized
> > +cartographic user agent may choose to transform the coordinate data
> to
> > +overlay the data. However, typical SVG user agents are not required
> > +to perform these types of transformations, or even recognize the
> > +metadata. It is described in this specification so that the
> connection
> > +between geographic coordinate systems and the SVG coordinate system
> is
> > +clear.
> > +
> > +<h2 id="SVGGlobalTransformAttribute">The <span class="attr-
> name">'svg:transform'</span> attribute</h2>
> > +
> > +<div class="adef-list">
> > + <p><em>Attribute definition:</em></p>
> > + <dl>
> > + <dt
> id="SVGGlobalTransformAttributeDefinition"><dfn>svg:transform</dfn> =
> <<transform-list>> | ''transform/none''</dt>
> > + <dd>
> > + <dl>
> > + <dt><<transform-list>></dt>
> > + <dd>
> > + <p>Specifies the affine transformation that has been
> > + applied to the map data. The syntax is identical to
> > + that described for the 'transform' property.</p>
> > + </dd>
> > +
> > + <dt><span class="attr-value">none</span></dt>
> > + <dd>
> > + <p>Specifies that no supplemental affine transformation
> has been
> > + applied to the map data. Using this value has the same
> meaning as
> > + specifying the identity matrix, which in turn is just the
> same as
> > + not specifying the <a>svg:transform</a> the attribute at
> all.</p>
> > + </dd>
> > + </dl>
> > + <p class="anim-target">Animatable: no.</p>
> > + </dd>
> > + </dl>
> > +</div>
> > +
> > +This attribute describes an optional additional affine
> > +transformation that may have been applied during this
> > +mapping. This attribute may be added to the OpenGIS
> > +<em>CoordinateReferenceSystem</em> element. Note
> > +that, unlike the 'transform' property, it does not indicate that
> > +a transformation is to <em>be applied</em> to the data within the
> file.
> > +Instead, it simply describes the transformation that <em>was already
> > +applied</em> to the data when being encoded in SVG.
> > +
> > +There are three typical uses for the <a>svg:transform</a>
> > +global attribute. These are described below and used in the
> examples.
> > +
> > +<ul>
> > + <li>Most ProjectedCRS have the north direction represented by
> > + positive values of the second axis and conversely SVG has a
> > + <var>y</var>-down coordinate system. That's why, in order to
> follow the
> > + usual way to represent a map with the north at its top, it is
> > + recommended for that kind of ProjectedCRS to use the
> > + <a>svg:transform</a>
> > + global attribute with a ''scale(1, -1)'' value as in the
> > + third example below.</li>
> > +
> > + <li>Most Geographic2dCRS have the latitude as their first
> > + axis rather than the longitude, which means that the
> > + south-north axis would be represented by the <var>x</var>-axis in
> SVG
> > + instead of the usual <var>y</var>-axis. That's why, in order to
> follow
> > + the usual way to represent a map with the north at its top,
> > + it is recommended for that kind of Geographic2dCRS to use the
> > + <a>svg:transform'</a>
> > + global attribute with a ''rotate(-90)'' value as in the
> > + first example (while also adding the ''scale(1, -1)'' as for
> > + ProjectedCRS).</li>
> > +
> > + <li>In addition, when converting for profiles which place
> > + restrictions on precision of real number values, it may be
> > + useful to add an additional scaling factor to retain good
> > + precision for a specific area. When generating an SVG
> > + document from WGS84 geographic coordinates (EPGS 4326), we
> > + recommend the use of an additional 100 times scaling factor
> > + corresponding to an <a>svg:transform</a>
> > + global attribute with a ''rotate(-90) scale(100)''
> > + value (shown in the second example).
> > + Different scaling values may be required depending on the
> > + particular CRS.</li>
> > +</ul>
> > +
> > +Below is a simple example of the coordinate metadata, which
> > +describes the coordinate system used by the document via a
> > +URI.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>An example that references coordinate data.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- The Coordinate Reference System is described
> > + through a URI. -->
> > + <crs:CoordinateReferenceSystem
> > + svg:transform="rotate(-90)"
> > +
> rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +The second example uses a well-known identifier to describe
> > +the coordinate system. Note that the coordinates used in the
> > +document have had the supplied transform applied.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Example using a well known coordinate system.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- In case of a well-known Coordinate Reference System
> > + an 'Identifier' is enough to describe the CRS -->
> > + <crs:CoordinateReferenceSystem svg:transform="rotate(-90)
> scale(100, 100)">
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > + </code></pre>
> > +</div>
> > +
> > +The third example defines the coordinate system completely
> > +within the SVG document.
> > +
> > +<div class="example">
> > + <pre><code class=html>
> > +<?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Coordinate metadata defined within the SVG
> document</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- For other CRS it should be entirely defined -->
> > + <crs:CoordinateReferenceSystem svg:transform="scale(1,-
> 1)">
> > + <crs:NameSet>
> > + <crs:name>Mercator projection of WGS84</crs:name>
> > + </crs:NameSet>
> > + <crs:ProjectedCRS>
> > + <!-- The actual definition of the CRS -->
> > + <crs:CartesianCoordinateSystem>
> > + <crs:dimension>2</crs:dimension>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>north</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>east</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + </crs:CartesianCoordinateSystem>
> > + <crs:CoordinateReferenceSystem>
> > + <!-- the reference system of that projected system
> is
> > + WGS84 which is EPSG 4326 in EPSG codeSpace
> -->
> > + <crs:NameSet>
> > + <crs:name>WGS 84</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + <crs:CoordinateTransformationDefinition>
> > + <crs:sourceDimensions>2</crs:sourceDimensions>
> > + <crs:targetDimensions>2</crs:targetDimensions>
> > + <crs:ParameterizedTransformation>
> > + <crs:TransformationMethod>
> > + <!-- the projection is a Mercator projection
> which is
> > + EPSG 9805 in EPSG codeSpace -->
> > + <crs:NameSet>
> > + <crs:name>Mercator</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>9805</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:description>Mercator
> (2SP)</crs:description>
> > + </crs:TransformationMethod>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Latitude of 1st standart
> parallel</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8823</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Longitude of natural
> origin</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8802</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Easting</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8806</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Northing</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8807</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + </crs:ParameterizedTransformation>
> > + </crs:CoordinateTransformationDefinition>
> > + </crs:ProjectedCRS>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- the actual map content -->
> > +</svg>
> > + </code></pre>
> > +</div>
> > \ No newline at end of file
> > diff --git a/specs/transform/Overview.html
> b/specs/transform/Overview.html
> > new file mode 100644
> > index 0000000..2510f34
> > --- /dev/null
> > +++ b/specs/transform/Overview.html
> > @@ -0,0 +1,681 @@
> > +<!doctype html>
> > +<html lang="en">
> > + <head>
> > +
> > + <meta content="text/html; charset=utf-8" http-equiv="Content-
> Type">
> > +
> > +
> > + <title>svg:transform for mapping</title>
> > +
> > +
> > + <link href="../default.css" rel="stylesheet" type="text/css">
> > +
> > +
> > + <link href="https://www.w3.org/StyleSheets/TR/W3C-ED"
> rel="stylesheet" type="text/css">
> > +
> > +
> > + <meta content="Bikeshed 1.0.0" name="generator">
> > + </head>
> > +
> > +
> > + <body class="h-entry">
> > +
> > + <div class="head">
> > +
> > + <p data-fill-with="logo"></p>
> > +
> > + <h1 class="p-name no-ref" id="title">svg:transform for
> mapping</h1>
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="subtitle"><span class="content">Editor’s Draft,
> > + <time class="dt-updated" datetime="2015-02-13">13 February
> 2015</time></span></h2>
> > +
> > + <div data-fill-with="spec-metadata">
> > + <dl>
> > + <dt>This version:
> > + <dd><a class="u-url" href="http://dev.w3.org/fxtf/motion-
> 1/">http://dev.w3.org/fxtf/motion-1/</a>
> > + <dt>Feedback:
> > + <dd><span><a href="mailto:www-svg@w3.org?subject=%5Btransform-
> mapping%5D%20feedback">www-svg@w3.org</a> with subject line
> “<kbd>[transform-mapping] <var>… message topic …</var></kbd>â€
> (<a href="http://lists.w3.org/Archives/Public/www-svg/"
> rel="discussion">archives</a>)</span>
> > + <dt class="editor">Editor:
> > + <dd class="editor">
> > + <div class="p-author h-card vcard"><a class="p-name fn u-email
> email" href="mailto:sa-takagi@kddi.com">Satoru Takagi</a> (<span
> class="p-org org">KDDI Corporation</span>)</div>
> > + </dl>
> > + </div>
> > +
> > + <div data-fill-with="warning"></div>
> > +
> > + <p class="copyright" data-fill-with="copyright"><a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#Copyright">Copyright</a> © 2015 <a
> href="http://www.w3.org/"><abbr title="World Wide Web
> Consortium">W3C</abbr></a><sup>®</sup> (<a
> href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute
> of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr
> title="European Research Consortium for Informatics and
> Mathematics">ERCIM</abbr></a>, <a
> href="http://www.keio.ac.jp/">Keio</a>, <a
> href="http://ev.buaa.edu.cn/">Beihang</a>). W3C <a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#Legal_Disclaimer">liability</a>, <a
> href="http://www.w3.org/Consortium/Legal/ipr-
> notice#W3C_Trademarks">trademark</a> and <a
> href="http://www.w3.org/Consortium/Legal/copyright-documents">document
> use</a> rules apply.
> > +</p>
> > +
> > + <hr title="Separator for header">
> > +</div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="abstract"><span class="content">Abstract</span></h2>
> > +
> > + <div class="p-summary" data-fill-with="abstract">
> > + <p>This specification gives guidance how the SVG transform
> attribute in the SVG namespace can be used in other context than
> SVG.</p>
> > +
> > +</div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled" id="status"><span
> class="content">Status of this document</span></h2>
> > +
> > + <div data-fill-with="status">
> > + <p>
> > + <em>This section describes the status of this document at the
> time of
> > + its publication. Other documents may supersede this document.
> A list of
> > + current W3C publications and the latest revision of this
> technical report
> > + can be found in the <a href="http://www.w3.org/TR/">W3C
> technical reports
> > + index at http://www.w3.org/TR/.</a></em>
> > +
> > +</p>
> > + <p>
> > + This document is the 13 February 2015 <strong>Editor’s
> Draft</strong> of svg:transform for mapping.
> > +
> > +</p>
> > + <p>
> > + Comments on this Editor’s Draft are welcome. Comments can
> be sent to
> > + <a href="mailto:www-svg@w3.org?Subject=%5Btransform-
> mapping%5D%20PUT%20SUBJECT%20HERE">www-svg@w3.org</a>,
> > + the public email list for issues related to vector graphics
> on the Web. This list is
> > + <a href="http://lists.w3.org/Archives/Public/www-
> svg/">archived</a> and senders must agree to have their message
> > + publicly archived from their first posting. To subscribe send
> an email to
> > + <a href="mailto:www-svg-
> request@w3.org?Subject=subscribe">www-svg-request@w3.org</a> with the
> word <code>subscribe</code>
> > + in the subject line.
> > +
> > +</p>
> > + <p>
> > + This document has been produced by the <a
> href="http://www.w3.org/Graphics/SVG/WG">SVG Working Group</a> as part
> of the
> > + <a href="http://www.w3.org/Graphics/Activity">Graphics
> Activity</a> within the
> > + <a href="http://www.w3.org/Interaction/">W3C Interaction
> Domain</a>. The goals of the W3C SVG Working Group are discussed in the
> > + <a href="http://www.w3.org/2007/11/SVG_rechartering/SVG-WG-
> charter.html">W3C SVG Charter</a>. The W3C SVG Working Group maintains
> a
> > + public Web page, <a
> href="http://www.w3.org/Graphics/SVG/">http://www.w3.org/Graphics/SVG/<
> /a>, that contains further
> > + background information. The authors of this document are the
> SVG Working Group participants.
> > +
> > +</p>
> > + <p>
> > + This document was produced by a group operating under
> > + the <a href="http://www.w3.org/Consortium/Patent-Policy-
> 20040205/">5 February 2004 W3C Patent Policy</a>.
> > + W3C maintains a <a href="http://www.w3.org/2004/01/pp-
> impl/19480/status" rel="disclosure">public list of any patent
> disclosures</a>
> > + made in connection with the deliverables of each group;
> > + these pages also includes instructions for disclosing a
> patent.
> > + An individual who has actual knowledge of a patent which the
> individual believes contains
> > + <a href="http://www.w3.org/Consortium/Patent-Policy-
> 20040205/#def-essential">Essential Claim(s)</a>
> > + must disclose the information in accordance with <a
> href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-
> Disclosure">section 6 of the W3C Patent Policy</a>.
> > +
> > +</p>
> > + <p>
> > + A list of current W3C Recommendations and other technical
> documents can be found at
> > + <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.
> W3C publications may be updated, replaced, or
> > + obsoleted by other documents at any time.
> > +</p></div>
> > +
> > + <div data-fill-with="at-risk"></div>
> > +
> > +
> > + <h2 class="no-num no-toc no-ref heading settled"
> id="contents"><span class="content">Table of contents</span></h2>
> > +
> > + <div data-fill-with="table-of-contents" role="navigation">
> > + <ul class="toc" role="directory">
> > + <li><a href="#GeographicCoordinates"><span
> class="secno">1</span> <span class="content">Geographic coordinate
> systems</span></a>
> > + <li><a href="#SVGGlobalTransformAttribute"><span
> class="secno">2</span> <span class="content">The <span class="attr-
> name">'svg:transform'</span> attribute</span></a>
> > + <li><a href="#conformance"><span class="secno"></span> <span
> class="content">
> > +Conformance</span></a>
> > + <ul class="toc">
> > + <li><a href="#conventions"><span class="secno"></span> <span
> class="content">
> > +Document conventions</span></a>
> > + <li><a href="#conformance-classes"><span class="secno"></span>
> <span class="content">
> > +Conformance classes</span></a>
> > + <li><a href="#partial"><span class="secno"></span> <span
> class="content">
> > +Partial implementations</span></a>
> > + <li><a href="#experimental"><span class="secno"></span> <span
> class="content">
> > +Experimental implementations</span></a>
> > + <li><a href="#testing"><span class="secno"></span> <span
> class="content">
> > +Non-experimental implementations</span></a>
> > + </ul>
> > + <li><a href="#references"><span class="secno"></span> <span
> class="content">References</span></a>
> > + <ul class="toc">
> > + <li><a href="#normative"><span class="secno"></span> <span
> class="content">Normative References</span></a>
> > + <li><a href="#informative"><span class="secno"></span> <span
> class="content">Informative References</span></a>
> > + </ul>
> > + <li><a href="#index"><span class="secno"></span> <span
> class="content">Index</span></a>
> > + </ul></div>
> > +
> > + <main>
> > +
> > +
> > +
> > +
> > +
> > + <h2 class="heading settled" data-level="1"
> id="GeographicCoordinates"><span class="secno">1. </span><span
> class="content">Geographic coordinate systems</span><a class="self-
> link" href="#GeographicCoordinates"></a></h2>
> > +
> > +
> > + <p>In order to allow interoperability between SVG content
> generators
> > +and user agents dealing with maps encoded in SVG, the use of a
> common
> > +metadata definition for describing the coordinate system used to
> > +generate SVG documents is encouraged.</p>
> > +
> > +
> > + <p>Such metadata must be added under the <a data-link-
> type="element" href="https://svgwg.org/svg2-
> draft/metadata.html#elementdef-metadata">metadata</a> element of
> > +the topmost <a data-link-type="element"
> href="https://svgwg.org/svg2-draft/struct.html#NewDocument">svg</a>
> element describing the map, consisting of an
> > +RDF description of the Coordinate Reference System definition used
> to
> > +generate the SVG map <a data-link-type="biblio" href="#biblio-rdf-
> primer">[RDF-PRIMER]</a>. Note that
> > +the presence of this metadata does not affect the rendering of the
> SVG
> > +in any way; it merely provides added semantic value for applications
> > +that make use of combined maps.</p>
> > +
> > +
> > + <p>The definition must be conformant to the XML grammar described
> in
> > +<a
> href="http://portal.opengeospatial.org/files/?artifact_id=20509"><cite>
> GML 3.2.1</cite></a>,
> > +an OpenGIS Standard for encoding common CRS data types in XML
> > +[<a href="refs.html#ref-GML">GML</a>]. In order to correctly map
> > +the 2-dimensional data used by SVG, the CRS must be of subtype
> > +<strong>ProjectedCRS</strong> or <strong>Geographic2dCRS</strong>.
> The
> > +first axis of the described CRS maps the SVG <var>x</var>-axis and
> the
> > +second axis maps the SVG <var>y</var>-axis.</p>
> > +
> > +
> > + <p>The main purpose of such metadata is to indicate to the user
> agent
> > +that two or more SVG documents can be overlayed or merged into a
> single
> > +document. Obviously, if two maps reference the same Coordinate
> Reference
> > +System definition and have the same SVG <a class="property" data-
> link-type="propdesc" href="http://dev.w3.org/csswg/css-transforms-
> 1/#propdef-transform">transform</a> property
> > +value then they can be overlayed without reprojecting the data. If
> > +the maps reference different Coordinate Reference Systems and/or
> have
> > +different SVG <a class="property" data-link-type="propdesc"
> href="http://dev.w3.org/csswg/css-transforms-1/#propdef-
> transform">transform</a> property values, then a specialized
> > +cartographic user agent may choose to transform the coordinate data
> to
> > +overlay the data. However, typical SVG user agents are not required
> > +to perform these types of transformations, or even recognize the
> > +metadata. It is described in this specification so that the
> connection
> > +between geographic coordinate systems and the SVG coordinate system
> is
> > +clear.</p>
> > +
> > +
> > + <h2 class="heading settled" data-level="2"
> id="SVGGlobalTransformAttribute"><span class="secno">2. </span><span
> class="content">The <span class="attr-name">'svg:transform'</span>
> attribute</span><a class="self-link"
> href="#SVGGlobalTransformAttribute"></a></h2>
> > +
> > +
> > + <div class="adef-list">
> > +
> > + <p><em>Attribute definition:</em></p>
> > +
> > + <dl>
> > +
> > + <dt id="SVGGlobalTransformAttributeDefinition"><a class="self-
> link" href="#SVGGlobalTransformAttributeDefinition"></a><dfn data-dfn-
> type="dfn" data-noexport="" id="svgtransform">svg:transform<a
> class="self-link" href="#svgtransform"></a></dfn> = <a
> class="production css" data-link-type="type"
> href="http://dev.w3.org/csswg/css-transforms-1/#typedef-transform-
> list"><transform-list></a> | <span class="css">none</span>
> > +
> > +
> > + <dd>
> > +
> > + <dl>
> > +
> > + <dt><a class="production css" data-link-type="type"
> href="http://dev.w3.org/csswg/css-transforms-1/#typedef-transform-
> list"><transform-list></a>
> > +
> > +
> > + <dd>
> > +
> > + <p>Specifies the affine transformation that has been
> > + applied to the map data. The syntax is identical to
> > + that described for the <a class="property" data-link-
> type="propdesc" href="http://dev.w3.org/csswg/css-transforms-
> 1/#propdef-transform">transform</a> property.</p>
> > +
> > +
> > +
> > +
> > +
> > + <dt><span class="attr-value">none</span>
> > +
> > +
> > + <dd>
> > +
> > + <p>Specifies that no supplemental affine transformation has
> been
> > + applied to the map data. Using this value has the same
> meaning as
> > + specifying the identity matrix, which in turn is just the
> same as
> > + not specifying the <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a> the attribute at all.</p>
> > +
> > +
> > +
> > +
> > + </dl>
> > +
> > +
> > + <p class="anim-target">Animatable: no.</p>
> > +
> > +
> > +
> > +
> > + </dl>
> > +</div>
> > +
> > +
> > + <p>This attribute describes an optional additional affine
> > +transformation that may have been applied during this
> > +mapping. This attribute may be added to the OpenGIS
> > +<em>CoordinateReferenceSystem</em> element. Note
> > +that, unlike the <a class="property" data-link-type="propdesc"
> href="http://dev.w3.org/csswg/css-transforms-1/#propdef-
> transform">transform</a> property, it does not indicate that
> > +a transformation is to <em>be applied</em> to the data within the
> file.
> > +Instead, it simply describes the transformation that <em>was already
> > +applied</em> to the data when being encoded in SVG.</p>
> > +
> > +
> > + <p>There are three typical uses for the <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a>
> > +global attribute. These are described below and used in the
> examples.</p>
> > +
> > +
> > + <ul>
> > +
> > + <li>Most ProjectedCRS have the north direction represented by
> > + positive values of the second axis and conversely SVG has a
> > + <var>y</var>-down coordinate system. That’s why, in order to
> follow the
> > + usual way to represent a map with the north at its top, it is
> > + recommended for that kind of ProjectedCRS to use the
> > + <a data-link-type="dfn" href="#svgtransform">svg:transform</a>
> > + global attribute with a <span class="css">scale(1, -1)</span>
> value as in the
> > + third example below.
> > +
> > +
> > + <li>Most Geographic2dCRS have the latitude as their first
> > + axis rather than the longitude, which means that the
> > + south-north axis would be represented by the <var>x</var>-axis in
> SVG
> > + instead of the usual <var>y</var>-axis. That’s why, in order to
> follow
> > + the usual way to represent a map with the north at its top,
> > + it is recommended for that kind of Geographic2dCRS to use the
> > + <a data-link-type="dfn" href="#svgtransform">svg:transform'</a>
> > + global attribute with a <span class="css">rotate(-90)</span> value
> as in the
> > + first example (while also adding the <span class="css">scale(1, -
> 1)</span> as for
> > + ProjectedCRS).
> > +
> > +
> > + <li>In addition, when converting for profiles which place
> > + restrictions on precision of real number values, it may be
> > + useful to add an additional scaling factor to retain good
> > + precision for a specific area. When generating an SVG
> > + document from WGS84 geographic coordinates (EPGS 4326), we
> > + recommend the use of an additional 100 times scaling factor
> > + corresponding to an <a data-link-type="dfn"
> href="#svgtransform">svg:transform</a>
> > + global attribute with a <span class="css">rotate(-90)
> scale(100)</span>
> > + value (shown in the second example).
> > + Different scaling values may be required depending on the
> > + particular CRS.
> > +</ul>
> > +
> > +
> > + <p>Below is a simple example of the coordinate metadata, which
> > +describes the coordinate system used by the document via a
> > +URI.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>An example that references coordinate data.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- The Coordinate Reference System is described
> > + through a URI. -->
> > + <crs:CoordinateReferenceSystem
> > + svg:transform="rotate(-90)"
> > +
> rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +
> > + <p>The second example uses a well-known identifier to describe
> > +the coordinate system. Note that the coordinates used in the
> > +document have had the supplied transform applied.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Example using a well known coordinate system.</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- In case of a well-known Coordinate Reference System
> > + an 'Identifier' is enough to describe the CRS -->
> > + <crs:CoordinateReferenceSystem svg:transform="rotate(-90)
> scale(100, 100)">
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- The actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +
> > +
> > + <p>The third example defines the coordinate system completely
> > +within the SVG document.</p>
> > +
> > +
> > + <div class="example">
> > +
> > + <pre><code class="html"><?xml version="1.0"?>
> > +<svg xmlns="http://www.w3.org/2000/svg"
> > + width="100" height="100" viewBox="0 0 1000 1000">
> > +
> > + <desc>Coordinate metadata defined within the SVG
> document</desc>
> > +
> > + <metadata>
> > + <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-
> ns#"
> > + xmlns:crs="http://www.ogc.org/crs"
> > + xmlns:svg="http://www.w3.org/2000/svg">
> > + <rdf:Description rdf:about="">
> > + <!-- For other CRS it should be entirely defined -->
> > + <crs:CoordinateReferenceSystem svg:transform="scale(1,-
> 1)">
> > + <crs:NameSet>
> > + <crs:name>Mercator projection of WGS84</crs:name>
> > + </crs:NameSet>
> > + <crs:ProjectedCRS>
> > + <!-- The actual definition of the CRS -->
> > + <crs:CartesianCoordinateSystem>
> > + <crs:dimension>2</crs:dimension>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>north</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + <crs:CoordinateAxis>
> > + <crs:axisDirection>east</crs:axisDirection>
> > + <crs:AngularUnit>
> > + <crs:Identifier>
> > + <crs:code>9108</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:AngularUnit>
> > + </crs:CoordinateAxis>
> > + </crs:CartesianCoordinateSystem>
> > + <crs:CoordinateReferenceSystem>
> > + <!-- the reference system of that projected system
> is
> > + WGS84 which is EPSG 4326 in EPSG codeSpace
> -->
> > + <crs:NameSet>
> > + <crs:name>WGS 84</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>4326</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + </crs:CoordinateReferenceSystem>
> > + <crs:CoordinateTransformationDefinition>
> > + <crs:sourceDimensions>2</crs:sourceDimensions>
> > + <crs:targetDimensions>2</crs:targetDimensions>
> > + <crs:ParameterizedTransformation>
> > + <crs:TransformationMethod>
> > + <!-- the projection is a Mercator projection
> which is
> > + EPSG 9805 in EPSG codeSpace -->
> > + <crs:NameSet>
> > + <crs:name>Mercator</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>9805</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:description>Mercator
> (2SP)</crs:description>
> > + </crs:TransformationMethod>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Latitude of 1st standart
> parallel</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8823</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>Longitude of natural
> origin</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8802</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Easting</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8806</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + <crs:Parameter>
> > + <crs:NameSet>
> > + <crs:name>False Northing</crs:name>
> > + </crs:NameSet>
> > + <crs:Identifier>
> > + <crs:code>8807</crs:code>
> > + <crs:codeSpace>EPSG</crs:codeSpace>
> > + <crs:edition>5.2</crs:edition>
> > + </crs:Identifier>
> > + <crs:value>0</crs:value>
> > + </crs:Parameter>
> > + </crs:ParameterizedTransformation>
> > + </crs:CoordinateTransformationDefinition>
> > + </crs:ProjectedCRS>
> > + </crs:CoordinateReferenceSystem>
> > + </rdf:Description>
> > + </rdf:RDF>
> > + </metadata>
> > +
> > + <!-- the actual map content -->
> > +</svg>
> > +</code></pre>
> > +</div>
> > +</main>
> > +
> > + <h2 class="no-ref no-num heading settled" id="conformance"><span
> class="content">
> > +Conformance</span><a class="self-link" href="#conformance"></a></h2>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="conventions"><span
> class="content">
> > +Document conventions</span><a class="self-link"
> href="#conventions"></a></h3>
> > +
> > +
> > + <p>Conformance requirements are expressed with a combination of
> > + descriptive assertions and RFC 2119 terminology. The key words
> "MUST",
> > + "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
> NOT",
> > + "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of
> this
> > + document are to be interpreted as described in RFC 2119.
> > + However, for readability, these words do not appear in all
> uppercase
> > + letters in this specification.
> > +
> > + </p>
> > + <p>All of the text of this specification is normative except
> sections
> > + explicitly marked as non-normative, examples, and notes. <a
> data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a></p>
> > +
> > +
> > + <p>Examples in this specification are introduced with the words
> "for example"
> > + or are set apart from the normative text with
> <code>class="example"</code>,
> > + like this:
> > +
> > + </p>
> > + <div class="example">
> > +
> > + <p>This is an example of an informative example.</p>
> > +
> > +
> > + </div>
> > +
> > +
> > + <p>Informative notes begin with the word "Note" and are set apart
> from the
> > + normative text with <code>class="note"</code>, like this:
> > +
> > + </p>
> > + <p class="note" role="note">Note, this is an informative note.</p>
> > +
> > +
> > + <p>Advisements are normative sections styled to evoke special
> attention and are
> > + set apart from other normative text with <code><strong
> class="advisement"></code>, like
> > + this:
> > +
> > + <strong class="advisement">
> > + UAs MUST provide an accessible alternative.
> > + </strong>
> > +
> > +</p>
> > + <h3 class="no-ref heading settled" id="conformance-classes"><span
> class="content">
> > +Conformance classes</span><a class="self-link" href="#conformance-
> classes"></a></h3>
> > +
> > +
> > + <p>Conformance to this specification
> > + is defined for three conformance classes:
> > + </p>
> > + <dl>
> > +
> > + <dt>style sheet
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#style-
> sheet">CSS
> > + style sheet</a>.
> > +
> > + <dt>renderer
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-
> agent">UA</a>
> > + that interprets the semantics of a style sheet and
> renders
> > + documents that use them.
> > +
> > + <dt>authoring tool
> > +
> > + <dd>A <a href="http://www.w3.org/TR/CSS21/conform.html#user-
> agent">UA</a>
> > + that writes a style sheet.
> > +
> > + </dl>
> > +
> > +
> > + <p>A style sheet is conformant to this specification
> > + if all of its statements that use syntax defined in this module
> are valid
> > + according to the generic CSS grammar and the individual grammars
> of each
> > + feature defined in this module.
> > +
> > + </p>
> > + <p>A renderer is conformant to this specification
> > + if, in addition to interpreting the style sheet as defined by
> the
> > + appropriate specifications, it supports all the features defined
> > + by this specification by parsing them correctly
> > + and rendering the document accordingly. However, the inability
> of a
> > + UA to correctly render a document due to limitations of the
> device
> > + does not make the UA non-conformant. (For example, a UA is not
> > + required to render color on a monochrome monitor.)
> > +
> > + </p>
> > + <p>An authoring tool is conformant to this specification
> > + if it writes style sheets that are syntactically correct
> according to the
> > + generic CSS grammar and the individual grammars of each feature
> in
> > + this module, and meet all other conformance requirements of
> style sheets
> > + as described in this module.
> > +
> > +</p>
> > + <h3 class="no-ref heading settled" id="partial"><span
> class="content">
> > +Partial implementations</span><a class="self-link"
> href="#partial"></a></h3>
> > +
> > +
> > + <p>So that authors can exploit the forward-compatible parsing
> rules to
> > + assign fallback values, CSS renderers <strong>must</strong>
> > + treat as invalid (and <a
> href="http://www.w3.org/TR/CSS21/conform.html#ignore">ignore
> > + as appropriate</a>) any at-rules, properties, property values,
> keywords,
> > + and other syntactic constructs for which they have no usable
> level of
> > + support. In particular, user agents <strong>must not</strong>
> selectively
> > + ignore unsupported component values and honor supported values
> in a single
> > + multi-value property declaration: if any value is considered
> invalid
> > + (as unsupported values must be), CSS requires that the entire
> declaration
> > + be ignored.</p>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="experimental"><span
> class="content">
> > +Experimental implementations</span><a class="self-link"
> href="#experimental"></a></h3>
> > +
> > +
> > + <p>To avoid clashes with future CSS features, the CSS2.1
> specification
> > + reserves a <a
> href="http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords">prefixed
> > + syntax</a> for proprietary and experimental extensions to CSS.
> > +
> > + </p>
> > + <p>Prior to a specification reaching the Candidate Recommendation
> stage
> > + in the W3C process, all implementations of a CSS feature are
> considered
> > + experimental. The CSS Working Group recommends that
> implementations
> > + use a vendor-prefixed syntax for such features, including those
> in
> > + W3C Working Drafts. This avoids incompatibilities with future
> changes
> > + in the draft.
> > + </p>
> > +
> > +
> > + <h3 class="no-ref heading settled" id="testing"><span
> class="content">
> > +Non-experimental implementations</span><a class="self-link"
> href="#testing"></a></h3>
> > +
> > +
> > + <p>Once a specification reaches the Candidate Recommendation
> stage,
> > + non-experimental implementations are possible, and implementors
> should
> > + release an unprefixed implementation of any CR-level feature
> they
> > + can demonstrate to be correctly implemented according to spec.
> > +
> > + </p>
> > + <p>To establish and maintain the interoperability of CSS across
> > + implementations, the CSS Working Group requests that non-
> experimental
> > + CSS renderers submit an implementation report (and, if
> necessary, the
> > + testcases used for that implementation report) to the W3C before
> > + releasing an unprefixed implementation of any CSS features.
> Testcases
> > + submitted to W3C are subject to review and correction by the CSS
> > + Working Group.
> > +
> > + </p>
> > + <p>Further information on submitting testcases and implementation
> reports
> > + can be found from on the CSS Working Group’s website at
> > + <a
> href="http://www.w3.org/Style/CSS/Test/">http://www.w3.org/Style/CSS/Te
> st/</a>.
> > + Questions should be directed to the
> > + <a href="http://lists.w3.org/Archives/Public/public-css-
> testsuite">public-css-testsuite@w3.org</a>
> > + mailing list.
> > +
> > +
> > +
> > +</p>
> > + <h2 class="no-num heading settled" id="references"><span
> class="content">References</span><a class="self-link"
> href="#references"></a></h2>
> > + <h3 class="no-num heading settled" id="normative"><span
> class="content">Normative References</span><a class="self-link"
> href="#normative"></a></h3>
> > + <dl>
> > + <dt id="biblio-rfc2119"><a class="self-link" href="#biblio-
> rfc2119"></a>[rfc2119]
> > + <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key
> words for use in RFCs to Indicate Requirement Levels</a>. March 1997.
> Best Current Practice. URL: <a
> href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/
> rfc2119</a>
> > + </dl>
> > + <h3 class="no-num heading settled" id="informative"><span
> class="content">Informative References</span><a class="self-link"
> href="#informative"></a></h3>
> > + <dl>
> > + <dt id="biblio-rdf-primer"><a class="self-link" href="#biblio-
> rdf-primer"></a>[rdf-primer]
> > + <dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/rdf-
> primer/">RDF Primer</a>. 10 February 2004. REC. URL: <a
> href="http://www.w3.org/TR/rdf-primer/">http://www.w3.org/TR/rdf-
> primer/</a>
> > + </dl>
> > + <h2 class="no-num heading settled" id="index"><span
> class="content">Index</span><a class="self-link"
> href="#index"></a></h2>
> > + <ul class="indexlist">
> > + <li>svg:transform, <a href="#svgtransform">2</a>
> > + </ul></body>
> > +</html>
> > \ No newline at end of file
> >
> >
> > ============================================================
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --list-toc-
> pages
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --list-
> nontoc-pages
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --build
> Overview toc coords
> > /home/svgwg/bin/node
> "/home/svgwg/svgwg.org/git/svgwg/tools/publish/publish.js" --build-
> single-page
> >
>
Received on Tuesday, 3 March 2015 18:54:26 UTC