SVG2/Specification authoring guide
Introduction
The SVG 2 specification is stored in the svg2 Mercurial repository. This repository is split into three directories:
The 'master' directory contains the master files for the specification. These files contain a lot of special processing instructions to generate and modify their contents, making them unsuitable for consumption by end users. The actual specification documents are created by running the file publish.py (found in the 'tools' directory) which produces/updates the contents of the 'publish' directory. Everything in the 'publish' directory is created by publish.py, so never modify this directory by hand.
The master directory
The master directory contains one XHTML file per chapter. It also contains a couple of special files.
publish.xml
publish.xml is a file that contains instructions to the build system on how the specification is structured and how it is to be built.
Its format is as follows, taking the existing SVG 1.1 Second Edition publish.xml as an example:
<publish-conf xmlns="http://mcc.id.au/ns/local"> <!-- The full title of the specification. --> <title>Scalable Vector Graphics (SVG) 1.1 (Second Edition)</title> <!-- A shorter version of the specification title, used in places like the links in the header/footer of each chapter to page to preceding/following chapters, and in the <title> of each chapter. --> <short-title>SVG 1.1 (Second Edition)</short-title> <!-- The W3C TR document maturity level. One of: ED, WG-NOTE, WD, FPWD, LCWD, FPLCWD, CR, PR, PER, REC, RSCND --> <maturity>ED</maturity> <!-- (Optional) Control for where the output of the build process goes. If omitted, the default is <output use-publish-directory="true" publish-directory="publish/"/> which means that the published version of the spec will be placed in a directory [specification-root]/publish/. --> <output use-publish-directory="true"/> <!-- (Optional) Overrides the document publication date in the output. This is normally not needed. In particular, it is not needed when doing a build of the specification for a TR publication (i.e., when <maturity> is set to anything other than "ED"), since the publication date will be automatically extracted from the URL specified in the <this> element, below. When <maturity> is set to "ED", the date used is the current date. --> <publication-date>2010-06-22</publication-date> <!-- Links for current/previous versions of the specification on w3.org. --> <versions> <!-- Link to the current Editor's Draft. --> <cvs href="http://dev.w3.org/SVG/profiles/1.1F2/publish/"/> <!-- Link to the next/upcoming TR publication. This one would normally have a placeholder URL, like you can see here. When it comes to publish the specification on the TR page, you would update the URL here and then rebuild. This URL is used for the "This version" link in the specification header. --> <this href="http://www.w3.org/TR/2011/PR-SVG11-2011xxxx/"/> <!-- (Optional) Link to the directly previous TR publication. This URL is used for the "Previous version" link in the specification header. --> <previous href="http://www.w3.org/TR/2010/WD-SVG11-20100622/"/> <!-- The "latest TR version of the specification" link. --> <latest href="http://www.w3.org/TR/SVG11/"/> <!-- (Optional) The "latest Recommendation of the specification" link. --> <latestrec href="http://www.w3.org/TR/SVG/"/> </versions> <!-- (Optional) The name of the definitions file for this specification. This typically would be called "definitions.xml". --> <definitions href="definitions.xml"/> <!-- (Optional) The name of the IDL-in-XML files for this specification. (The IDLX is currently generated from the IDL in a separate step before the publish.xsl, which processes this publish.xml files, runs.) --> <interfaces idl="svg.idlx"/> <!-- (Optional) The name of a file to write a separate page Expanded Table of Contents to. --> <toc href="expanded-toc.html"/> <!-- (Optional) The name of a file to write an element index to. --> <elementindex href="eltindex.html"/> <!-- (Optional) The name of a file to write an attribute index to. --> <attributeindex href="attindex.html"/> <!-- (Optional) The name of a file to write a property index to. --> <propertyindex href="propidx.html"/> <!-- The following elements specify all of separate pages/chapters of the specification, with the ".html" omitted. The order of the <page>, <chapter> and <appendix>es is significant. --> <!-- The "main page" of the specification. If this is only a one page specification, then this is the only element needed. --> <index name="index"/> <!-- (Optional) A <page> element is used for a non-chapter, non-appendix separate HTML file of the specification. It will appear in the Table of Contents, and can be navigated to from the header/footer links, but is not classified as chapter or appendix for numbering. --> <page name="expanded-toc"/> <!-- (Optional) A <chapter> element is used for a numbered chapter in the specification. --> <chapter name="intro"/> <chapter name="concepts"/> ... <chapter name="backward"/> <chapter name="extend"/> <!-- (Optional) An <appendix> element is used for a numbered (with letters!) appendix in the specification. --> <appendix name="svgdtd"/> <appendix name="svgdom"/> ... <appendix name="refs"/> <appendix name="eltindex"/> <appendix name="attindex"/> <appendix name="propidx"/> <appendix name="feature"/> <appendix name="mimereg"/> <appendix name="changes"/> </publish-conf>
definitions.xml
The definitions file holds information about elements, attributes, properties, interfaces, grammar symbols and defined terms. The main reason for including information about these things in the definitions file is so that the build system can automatically generate links to them without having to write out a complete link like
<a href="shapes.html#RectElement"><span class="element-name">'svg'</span></a>
every time you want to reference the <svg> element. But there are various other automatically generated parts of the specification that use the information in this file.
The definitions file for SVG 1.1 Second Edition is quite large, so instead of reproducing it here in its entirety, we will go through selected examples taken from it.
The definitions file is structured with a root <definitions xmlns="http://mcc.id.au/ns/local"> element, inside which there can be any number of the following elements:
- <element> – information about an element defined in the specification (such as "rect")
- <elementcategory> – information about a category of elements defined in the specification (such as "filter primitive elements"), used when defining the content model of other elements
- <attribute> – information about an attribute defined in the specification (such as "id")
- <attributecategory> – information about a category of attributes defined in the specification (such as "conditional processing attributes"), used when defining the attributes allowed on a given element
- <property> – information about a CSS property defined in the specification (such as "stroke-width")
- <interface> – information about a DOM interface defined in the specification (such as "SVGSVGElement")
- <symbol> – information about grammar symbol defined in the specification (such as "<paint>")
- <term> – information about term defined in the specification (such as "outermost svg element")
Elements
The <element> element is used to declare information about an element defined in the specification. Here are some examples:
<element
name="rect"
href="shapes.html#RectElement"
contentmodel="anyof"
elementcategories="animation, descriptive"
attributecategories="conditional processing, core, graphical event, presentation, style"
attributes="externalResourcesRequired, transform"
interfaces="SVGRectElement">
<attribute name="x" href="shapes.html#RectElementXAttribute" animatable="yes"/>
<attribute name="y" href="shapes.html#RectElementYAttribute" animatable="yes"/>
<attribute name="width" href="shapes.html#RectElementWidthAttribute" animatable="yes"/>
<attribute name="height" href="shapes.html#RectElementHeightAttribute" animatable="yes"/>
<attribute name="rx" href="shapes.html#RectElementRXAttribute" animatable="yes"/>
<attribute name="ry" href="shapes.html#RectElementRYAttribute" animatable="yes"/>
</element>
The name attribute gives the name of the element.
The href attribute gives the link to the element's definition in the spec. In a multi-page spec, like SVG 1.1 Second Edition, this needs to be a link to a particular chapter, as seen here. In a single-page spec, using a bare fragment would be fine.
The contentmodel attribute specifies what elements are allowed to appear as children of the element in a valid document. The value that would be used most commonly is "anyof", which means that zero or more of the elements identified by the elementcategories and elements attributes can appear as childern of the element, in any order. Other values that can be used for the contentmodel attribute are "textoranyof", "oneormoreof", "any" and "text". "any" means that any child content is allowed, "text" means that only text content is allowed, and "textoranyof" and "oneormoreof" mean text interleaved with zero or more, or one or more, of the content model elements, in any order.
The elementcategories attribute identifies categories of elements that are part of this element's content model. It is a comma separate list of element category names, and each of these names must correspond to an <elementcategory name="..."> in the definitions file.
The attributecategories attribute identifies categories of attributes that can appear on this element. It is a comma separated list of attribute category names, and each of these names must correspond to an <attributecategory name="..."> in the definitions file.
The attributes attribute identifies additional single attributes that can appear on this element. It is a comma separated list of attribte names, and each of these names must correspond to an <attribute name="..."> at the top level of the definitions file.
The interfaces attribute identifies which IDL interfaces are implemented by DOM objects for this element type. It is a comma separated list of interface names, and each of these names must correspond to an <interface name="..."> in the definitions file.
The child <attribute> elements identify attributes that appear only on this element. (This is unlike those identified by the attributecategories and attributes attributes, which reference attributes whose definitions are common to multiple elements.) The name attribute gives the name of the attribute, href is the link to the attribute definition, and the animatable attribute specifies whether the attribute is animatable. (The default is animatable="no", so it can be omitted if the attribute is not animatable.)
So even though there are various elements in the specification that have a width attribute, the <rect> element has its particular definition of the attribute at shapes.html#RectElementWidthAttribute. On the other hand, there's only one definition of transform in the spec, so there is only <attribute name="transform"> element defined at the top level of the file, and which elements reference from <element attributes="...">.
<element
name="feDiffuseLighting"
href="filters.html#feDiffuseLightingElement"
attributecategories="core, style, presentation, filter primitive"
attributes="in"
interfaces="SVGFEDiffuseLightingElement">
<x:contentmodel xmlns="http://www.w3.org/1999/xhtml">Any number of <a>descriptive elements</a>
and exactly one <a>light source element</a>, in any order.</x:contentmodel>
<attribute name="surfaceScale" href="filters.html#feDiffuseLightingSurfaceScaleAttribute" animatable="yes"/>
<attribute name="diffuseConstant" href="filters.html#feDiffuseLightingDiffuseConstantAttribute" animatable="yes"/>
<attribute name="kernelUnitLength" href="filters.html#feDiffuseLightingKernelUnitLengthAttribute" animatable="yes"/>
</element>
This is an example of an element with a custom content model, specified in HTML prose. (The x prefix there is just bound to http://mcc.id.au/ns/local, like all of the other non-HTML elements in the file.)
Some elements might not have any <attribute> children, since they only allow common attributes on them, like <g> does:
<element
name="g"
href="struct.html#GElement"
contentmodel="anyof"
elementcategories="animation, descriptive, shape, structural, gradient"
elements="a, clipPath, color-profile, cursor, filter, font, font-face, foreignObject, image, marker, mask,
pattern, script, style, switch, view, text, altGlyphDef"
attributecategories="conditional processing, core, graphical event, presentation, style"
attributes="externalResourcesRequired, transform"
interfaces="SVGGElement"/>
Element categories
Element categories are named groups of elements. They are grouped together to ease specifying the content model of other elements. As an example:
<elementcategory name="container" href="intro.html#TermContainerElement" elements="svg, g, defs, symbol, mask, pattern, marker, a, switch, glyph, missing-glyph"/>
This defined an element category named "container", with the given element names in the elements attribute as members. The href is a link to a definition in the spec for that group of elements.
Attributes
Attributes defined at the top level of the definitions file are those that are applicable to multiple elements, and which have a single definition in the spec. For example:
<attribute name="xlink:href" elements="animate, animateColor, animateMotion, animateTransform, set" href="animate.html#HrefAttribute"/>
This defines an xlink:href attribute that is applicable to the specified animation elements. Note that the definition for, say, the <set> element specifies that an attribute named xlink:href is allowed by it having "xlink" in its attributecategories attribute:
<element
name="set"
href="animate.html#SetElement"
contentmodel="anyof"
elementcategories="descriptive"
attributecategories="conditional processing, core, animation event, xlink,
animation attribute target, animation timing"
attributes="externalResourcesRequired"
interfaces="SVGSetElement">
<attribute name="to" href="animate.html#SetElementToAttribute"/>
</element>
<attributecategory
name="xlink"
href="intro.html#TermXLinkAttributes"
attributes="xlink:href, xlink:show, xlink:actuate">
<attribute name="xlink:type" href="linking.html#XLinkTypeAttribute"/>
<attribute name="xlink:role" href="linking.html#XLinkRoleAttribute"/>
<attribute name="xlink:arcrole" href="linking.html#XLinkArcRoleAttribute"/>
<attribute name="xlink:title" href="linking.html#XLinkTitleAttribute"/>
</attributecategory>
Attributes that are defined to apply to more than one element like this must be linked both ways: the <attribute> references the elements it can appear on in its elements attribute, and each <element> that allows it must specify it in its attributes attribute or indirectly via its attributecategories attribute.
Attribute categories
Attribute categories are named sets of attributes that are used in defining the allowable attributes on a given element. For example:
<attributecategory
name="conditional processing"
href="intro.html#TermConditionalProcessingAttribute">
<attribute name="requiredFeatures" href="struct.html#RequiredFeaturesAttribute"/>
<attribute name="requiredExtensions" href="struct.html#RequiredExtensionsAttribute"/>
<attribute name="systemLanguage" href="struct.html#SystemLanguageAttribute"/>
</attributecategory>
Elements reference these categories in their attributecategories attributes, as seen in some of the examples above. The name attribute gives the name of the attribute category, and the href attribute gives a link to the definition of the attribute category.
Properties
Properties are defined very simply:
<property name="fill" href="painting.html#FillProperty"/>
Since any properties can be specified on any stylable element even if they don't apply, there is no need to specify which elements a given property can appear on.
The definitions for stylable elements is done like this:
<attributecategory
name="style">
<attribute name="class" href="styling.html#ClassAttribute" animatable="yes"/>
<attribute name="style" href="styling.html#StyleAttribute"/>
</attributecategory>
<attributecategory
name="presentation"
href="intro.html#TermPresentationAttribute"
presentationattributes="alignment-baseline, baseline-shift, clip, clip-path,
...
unicode-bidi, visibility, word-spacing, writing-mode"/>
<element
name="path"
href="paths.html#PathElement"
contentmodel="anyof"
elementcategories="animation, descriptive"
attributecategories="conditional processing, core, graphical event, presentation, style"
attributes="externalResourcesRequired, transform"
interfaces="SVGPathElement">
<attribute name="d" href="paths.html#DAttribute" animatable="yes"/>
<attribute name="pathLength" href="paths.html#PathLengthAttribute" animatable="yes"/>
</element>
So a stylable element like <path will reference the "presentation" and "style" attribute categories to allow the attribute style, class, fill, stroke, etc. on it.
Notice the use of presentationattributes on the "presentation" attribute category: this is used instead of attributes so that when the attribute table appendix is generated, regular and presentation attributes can be separated. (On <attributecategory name="presentation"> is the only place where there is a presentationattributes attribute.)
Interfaces
Interfaces are listed in the definitions file to associate a link with them, for example:
<interface name="SVGSVGElement" href="struct.html#InterfaceSVGSVGElement"/>
Grammar symbols
Grammar symbols are also listed in the definitions file to associate a link with them, for example:
<symbol name="length" href="types.html#DataTypeLength"/>
Terms
Terms are named, prose definitions in the specification that should be linked to whenever the term is mentioned. They are listed in the definitions file like this:
<term name="local IRI reference" href="intro.html#TermLocalIRIReference"/> <term name="local IRI references" href="intro.html#TermLocalIRIReference"/>
It is common to have entries for different forms of the term (like singular and plural) so that automatic linking can work for all of those forms.
Importing definitions
It is actually possible to import definitions from another specification's definitions file. This is useful if you are writing a module and wish to have, say, links to SVG 1.1 elements that are not defined in that module.
This isn't actually important until we get specifications other than SVG 2 into the Mercurial repository, so I will describe importing later. --Cameron McCormack 05:36, 23 March 2011 (UTC)
Chapter format
The markup used in the specification is XHTML plus some other-namespaced elements that cause some magic to happen. (Magic also happens with some plain XHTML content, too.) This section describes how to write content to get the most out of the build system.
Chapter and appendix files are structured like this:
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional+edit//EN" "xhtml1-transitional+edit.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:edit="http://xmlns.grorg.org/SVGT12NG/"> <head> <title>Chapter Title</title> <link rel="stylesheet" type="text/css" media="screen" href="style/svg-style.css"/> <link rel="stylesheet" type="text/css" media="screen" href="style/svg-style-extra.css"/> <link rel="stylesheet" type="text/css" media="print" href="style/svg-style-print.css"/> </head> <body> <h1>Chapter Title</h1> <p>Some body text.</p> <h2 id="SectionID">A section in the chapter.</h2> <p>More text.</p> <h2 id="AnotherSectionID">Another section.</h2> ... </body> </html>
The edit prefix is for the foreign elements that do some special processing. (The actualy namespace URI is a legacy from the SVG 1.2 Tiny build system, from where these processing elements are derived.)
Avoid including a chapter-specific <style> element in the file, since it will be omitted when the single page version of the specification is generated.
Note that separate sections are not wrapped in a <div> or any other block level element. Heading elements and actual content all appears as children of the <body>. To avoid unnecessary waste of horiztonal space, direct child elements of <body> should be placed in column 1.
The table of contents in a chapter is generated automatically below the <h1> without any need to include a special processing element.
Processing instructions
Some forms of markup cause the build system to do some special processing. This section documents all of them.
Section numbers
Section numbers are generated automatically for <h2> – <h6> elements, and no additional markup is required for this. Every section header element must have an ID, since it will be linked to from the chapter's Table of Contents (as well as the Extended Table of Contents). An ID isn't generated for you.
Linking to sections
Linking to other sections must be done manually, like the following:
<p>For further details, see the <a href="types.html#BasicDataTypes">Basic data types</a> section.</p>
Make sure you use a relative link like this. (The script that generates the single page version of the spec does a bunch of ID rewriting for uniqueness, and will automatically rewrite links like the above.) For links within the current chapter, a bare fragment is fine too.
Linking to elements, attributes and properties
Most of the magic that the build system can do is generating links for you.
To link to the definition of an element, attribute or property, you write <a>'blah'</a>, where blah is the name of the thing you are linking to. For example:
<p>You can use the <a>'rect'</a> element to draw rectangles.</p> <p>Specify a <a>'class'</a> attribute on it to give it a CSS class.</p> <p>I like to set the <a>'stroke-width'</a> to <span class="prop-value">4px</span>.</p>
These use the definitions file to generate the value of the href attribute and the styling of the link.
Sometimes it will be ambiguous as to whether the link should be to an element, an attribute or a property. For example if you write:
<p>Here is an example that uses <a>'mask'</a>.</p>
then it is unclear whether that should be a link to the <cursor> element or the 'cursor' property. In most cases, when the link would be ambiguous, the build system will emit an error message and stop the build. In that case you need to explicitly disambiguate it:
<p>Here is an example that uses <a>'mask property'</a>.</p>
or
<p>Here is an example that uses <a>'mask element'</a>.</p>
When referencing an attribute that is not specific to any particular element, such as class, then writing <a>'class'</a> will be sufficient. Many attributes, though, have specific definitions for a particular element. In those cases, say for the width attribute on <rect>, then writing the following will cause the build system to stop with an error:
<p>The <a>'width'</a> attribute is the width of the rectangle.</p>
There are two ways to solve this. One is to specify which element the attribute is on:
<p>The <a>'rect/width'</a> attribute is the width of the rectangle.</p>
(The "rect/" part of the text there won't appear in the output; the generated link will look like ‘width’.)
The second way is to surround a section with an <edit:with> element that provides the context for attribute lookups:
<edit:with element="rect"> <h2 id="RectAttributes">The attributes you can stick on <span class="attr-name">rect</span></h2> <p>The <a>'width'</a> and <a>'height'</a> attributes are used to specify the size of a rectangle.</p> ... </edit:with>
This can be handy for sections that define a given element, so that you don't need to continually specify the <a>'elementname/attributename'</a> form. (Most element definition sections in the specification are already surrounded with a corresponding <edit:with> element.)
Linking to interfaces and interface members
DOM interfaces can be linked to in a similar manner, like so:
<p>All <a>'rect'</a> elements implement the <a>SVGRectElement</a> interface.</p>
Linking to members of an interface (their operations, attributes or constants) is done like so:
<p>To get the bounding box of a shape, call the <a>SVGLocatable::getBBox</a> method.</p>
The href attribute of the corresponding <interface> element in the definitions file will be used as the link.
Linking to grammar symbols
Grammar symbols are linked to like this:
<p>The <a>'stroke-width'</a> property takes a <a><length></a> value.</p>
The href attribute of the corresponding <symbol> element in the definitions file will be used as the link.
Linking to terms
Terms are linked to like this:
<p>All <a>container elements</a> can have <a>graphical elements</a> as children.</p>
The exact textual contents of the <a> is matched against the name attribute of the <term> elements in the definitions file to find the href value to use.
There's no way currently to link to a term automatically while using a variation of the wording that doesn't appear in the definitions file.
Simple substitutions
A number of <edit:*> elements are used to insert some generated content into the document, many of which you don't need to use in the main body of the specification. Here are the important ones:
<edit:interface name="interface name"/>
This is used in the body of the specification to insert the IDL for a given interface along with the definitions of its operations, attributes and constants.
<edit:example href="images/chapter/example-filename.svg name="example-name" description="..." link="yes|no" image="yes|no"/>
This is used to include an example from an external example file. The href link is to the SVG file, and it is relative to the top level specification directory. Most examples are in a directory named images/blah/ where "blah" is the chapter name.
The name attribute is a short string identifying the example, and seems to be normally the same as the base name of the actual SVG file.
The description attribute gives a short description of the example, which will be included just below the example.
The link attribute is used to control whether a link to the external SVG example file will be included.
The image attribute is used to control whether the PNG rendering of the example (which must be at the same location as the href but ending with ".png" instead of ".svg") is included below the example listing.
<edit:includefile href="filename"/> – used to insert the plain text contents of a file.
<edit:elementsummary name="element name"/> – used to insert the blue box summary for an element.
<edit:locallink href="some file"/> – used to generate an absolute URL for a file distributed with the specification. For example, it is used in the idl.html appendix to generate the absolute URL for the SVG IDL file, like this:
<pre><edit:locallink href="svg.idl"/></pre>
The final output looks like:
<pre><a href="http://www.w3.org/2011/WD-SVG11-20110123/svg.idl">http://www.w3.org/2011/WD-SVG11-20110123/svg.idl</a></pre>
The following are less commonly used:
<edit:elementcategory name="element category name"/> – used in various parts of the specification to generate the list of elements that are part of the given category. For example, in intro.html, there is:
<dt id="TermFilterPrimitiveElement">filter primitive element</dt> <dd>A filter primitive element is one that can be used as a child of a <a>'filter element'</a> element to specify a node in the filter graph. The following elements are the filter primitive elements defined in SVG 1.1: <edit:elementcategory name="filter primitive"/>.</dd>
<edit:attributecategory name="attribute category name"/> – used in various parts of the specification to generate the list of elements that are part of the given category. For example, in intro.html, there is:
<dt id="TermFilterPrimitiveAttributes">filter primitive attributes</dt> <dd>The filter primitive attributes is the set of attributes that are common to all <a>filter primitive elements</a>. They are <edit:attributecategory name="filter primitive"/>.</dd>
<edit:elementswithattributecategory name="attribute category name"/> – used to generate a list of elements that are defined to allow attributes in a given category. It is used in a couple of places, such as in the attribute table appendix to generate the list of elements on which presentation attributes can be specified. <edit:minitoc/> – used in index.html to insert the front page table of contents.
<edit:fulltoc/> – used in expanded-toc.html to insert the full table of contents.
<edit:completeidl/> – used in the idl.html appendix to insert the entire IDL (without interface descriptions), with links to the definitions for each interface and interface member.
<edit:maturity/> – used in the header of index.html to include the full maturity level string for the document, such as "Working Draft". The maturity is taken from the <maturity> element in publish.xml.
<edit:date/> – used in the header of index.html to include the publication date of the document in the format "dd MMMM yyyy". This is taken from information in publish.xml, as described above.
<edit:thisversion/> – used in the header of index.html to include the "This version" link of the specification.
<edit:latestversion/> – used in the header of index.html to include the "Latest version" link of the specification.
<edit:previousversion/> – used in the header of index.html to include the "Previous version" link of the specification.
<edit:copyright/> – used in the header of index.html to generate the correct copyright string for the document based on the year of the publication date.
<edit:attributetable/> – used in the attribute table appendix to generate the table of attributes and which elements they can be specified on.
Other things current unexplained
- edit:toc="no" attribute
- edit:format="expanded" attribute
Final XML structure
CSS classes
Making a change
For SVG 1.1 Second Edition, to republish your changes, do the following:
- Run cvs up in the publish/ directory, to make sure you don't have out of date files in there before they are overritten (else CVS will complain at you).
- Run make in the master/ directory.
- In SVG/profiles/1.1F2/, run cvs commit master publish to commit your changes including the republished version of the specification.
The procedure will be a little different for SVG 2, as described below.