Geospatial decision in W3C SVG WG: Move svg:transform mapping to its own spec

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/637ae4967c0b923a97c5c8f82ac530d44823d1a3

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/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-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>&lt;transform-function&gt;</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>&lt;transform-function&gt;</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>
+&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>An example that references coordinate data.&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- The Coordinate Reference System is described
+             through a URI. -->
+        &lt;crs:CoordinateReferenceSystem
+            svg:transform="rotate(-90)"
+            rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- The actual map content -->
+&lt;/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>
+&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>Example using a well known coordinate system.&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- In case of a well-known Coordinate Reference System
+             an 'Identifier' is enough to describe the CRS -->
+        &lt;crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
+          &lt;crs:Identifier>
+            &lt;crs:code>4326&lt;/crs:code>
+            &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+            &lt;crs:edition>5.2&lt;/crs:edition>
+          &lt;/crs:Identifier>
+        &lt;/crs:CoordinateReferenceSystem>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- The actual map content -->
+&lt;/svg>
+  </code></pre>
+</div>
+
+The third example defines the coordinate system completely
+within the SVG document.
+
+<div class="example">
+  <pre><code class=html>
+&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>Coordinate metadata defined within the SVG document&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- For other CRS it should be entirely defined -->
+        &lt;crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
+          &lt;crs:NameSet>
+            &lt;crs:name>Mercator projection of WGS84&lt;/crs:name>
+          &lt;/crs:NameSet>
+          &lt;crs:ProjectedCRS>
+            &lt;!-- The actual definition of the CRS -->
+            &lt;crs:CartesianCoordinateSystem>
+              &lt;crs:dimension>2&lt;/crs:dimension>
+              &lt;crs:CoordinateAxis>
+                &lt;crs:axisDirection>north&lt;/crs:axisDirection>
+                &lt;crs:AngularUnit>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9108&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                &lt;/crs:AngularUnit>
+              &lt;/crs:CoordinateAxis>
+              &lt;crs:CoordinateAxis>
+                &lt;crs:axisDirection>east&lt;/crs:axisDirection>
+                &lt;crs:AngularUnit>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9108&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                &lt;/crs:AngularUnit>
+              &lt;/crs:CoordinateAxis>
+            &lt;/crs:CartesianCoordinateSystem>
+            &lt;crs:CoordinateReferenceSystem>
+              &lt;!-- the reference system of that projected system is
+                         WGS84 which is EPSG 4326 in EPSG codeSpace -->
+              &lt;crs:NameSet>
+                &lt;crs:name>WGS 84&lt;/crs:name>
+              &lt;/crs:NameSet>
+              &lt;crs:Identifier>
+                &lt;crs:code>4326&lt;/crs:code>
+                &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                &lt;crs:edition>5.2&lt;/crs:edition>
+              &lt;/crs:Identifier>
+            &lt;/crs:CoordinateReferenceSystem>
+            &lt;crs:CoordinateTransformationDefinition>
+              &lt;crs:sourceDimensions>2&lt;/crs:sourceDimensions>
+              &lt;crs:targetDimensions>2&lt;/crs:targetDimensions>
+              &lt;crs:ParameterizedTransformation>
+                &lt;crs:TransformationMethod>
+                  &lt;!-- the projection is a Mercator projection which is
+                        EPSG 9805 in EPSG codeSpace -->
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Mercator&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9805&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:description>Mercator (2SP)&lt;/crs:description>
+                &lt;/crs:TransformationMethod>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Latitude of 1st standart parallel&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8823&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Longitude of natural origin&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8802&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>False Easting&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8806&lt;/crs:code>         
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>False Northing&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8807&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+              &lt;/crs:ParameterizedTransformation>
+            &lt;/crs:CoordinateTransformationDefinition>
+          &lt;/crs:ProjectedCRS>
+        &lt;/crs:CoordinateReferenceSystem>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- the actual map content -->
+&lt;/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">&lt;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">&lt;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">&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>An example that references coordinate data.&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- The Coordinate Reference System is described
+             through a URI. -->
+        &lt;crs:CoordinateReferenceSystem
+            svg:transform="rotate(-90)"
+            rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- The actual map content -->
+&lt;/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">&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>Example using a well known coordinate system.&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- In case of a well-known Coordinate Reference System
+             an 'Identifier' is enough to describe the CRS -->
+        &lt;crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
+          &lt;crs:Identifier>
+            &lt;crs:code>4326&lt;/crs:code>
+            &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+            &lt;crs:edition>5.2&lt;/crs:edition>
+          &lt;/crs:Identifier>
+        &lt;/crs:CoordinateReferenceSystem>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- The actual map content -->
+&lt;/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">&lt;?xml version="1.0"?>
+&lt;svg xmlns="http://www.w3.org/2000/svg"
+     width="100" height="100" viewBox="0 0 1000 1000">
+
+  &lt;desc>Coordinate metadata defined within the SVG document&lt;/desc>
+
+  &lt;metadata>
+    &lt;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">
+      &lt;rdf:Description rdf:about="">
+        &lt;!-- For other CRS it should be entirely defined -->
+        &lt;crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
+          &lt;crs:NameSet>
+            &lt;crs:name>Mercator projection of WGS84&lt;/crs:name>
+          &lt;/crs:NameSet>
+          &lt;crs:ProjectedCRS>
+            &lt;!-- The actual definition of the CRS -->
+            &lt;crs:CartesianCoordinateSystem>
+              &lt;crs:dimension>2&lt;/crs:dimension>
+              &lt;crs:CoordinateAxis>
+                &lt;crs:axisDirection>north&lt;/crs:axisDirection>
+                &lt;crs:AngularUnit>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9108&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                &lt;/crs:AngularUnit>
+              &lt;/crs:CoordinateAxis>
+              &lt;crs:CoordinateAxis>
+                &lt;crs:axisDirection>east&lt;/crs:axisDirection>
+                &lt;crs:AngularUnit>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9108&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                &lt;/crs:AngularUnit>
+              &lt;/crs:CoordinateAxis>
+            &lt;/crs:CartesianCoordinateSystem>
+            &lt;crs:CoordinateReferenceSystem>
+              &lt;!-- the reference system of that projected system is
+                         WGS84 which is EPSG 4326 in EPSG codeSpace -->
+              &lt;crs:NameSet>
+                &lt;crs:name>WGS 84&lt;/crs:name>
+              &lt;/crs:NameSet>
+              &lt;crs:Identifier>
+                &lt;crs:code>4326&lt;/crs:code>
+                &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                &lt;crs:edition>5.2&lt;/crs:edition>
+              &lt;/crs:Identifier>
+            &lt;/crs:CoordinateReferenceSystem>
+            &lt;crs:CoordinateTransformationDefinition>
+              &lt;crs:sourceDimensions>2&lt;/crs:sourceDimensions>
+              &lt;crs:targetDimensions>2&lt;/crs:targetDimensions>
+              &lt;crs:ParameterizedTransformation>
+                &lt;crs:TransformationMethod>
+                  &lt;!-- the projection is a Mercator projection which is
+                        EPSG 9805 in EPSG codeSpace -->
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Mercator&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>9805&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:description>Mercator (2SP)&lt;/crs:description>
+                &lt;/crs:TransformationMethod>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Latitude of 1st standart parallel&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8823&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>Longitude of natural origin&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8802&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>False Easting&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8806&lt;/crs:code>         
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+                &lt;crs:Parameter>
+                  &lt;crs:NameSet>
+                    &lt;crs:name>False Northing&lt;/crs:name>
+                  &lt;/crs:NameSet>
+                  &lt;crs:Identifier>
+                    &lt;crs:code>8807&lt;/crs:code>
+                    &lt;crs:codeSpace>EPSG&lt;/crs:codeSpace>
+                    &lt;crs:edition>5.2&lt;/crs:edition>
+                  &lt;/crs:Identifier>
+                  &lt;crs:value>0&lt;/crs:value>
+                &lt;/crs:Parameter>
+              &lt;/crs:ParameterizedTransformation>
+            &lt;/crs:CoordinateTransformationDefinition>
+          &lt;/crs:ProjectedCRS>
+        &lt;/crs:CoordinateReferenceSystem>
+      &lt;/rdf:Description>
+    &lt;/rdf:RDF>
+  &lt;/metadata>
+
+  &lt;!-- the actual map content -->
+&lt;/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>&lt;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/Test/</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, 24 February 2015 10:53:27 UTC