View source

From SVG

You do not have permission to do that, for the following reasons:

• The action you have requested is limited to users in one of the groups Sysops, svgEditors.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

To create a new specification or module, you can use the [http://dev.w3.org/SVG/modules/template/ template] spec as a model. This is a stripped-down, empty module with some of the more common bits that are needed for an SVG spec. ==Template Files== The [http://dev.w3.org/SVG/modules/template/ template folder] contains several files: * [http://dev.w3.org/SVG/modules/template/SVGTemplate.html SVG Template]: this is the main file, and the only one that's strictly necessary. This document contains normative prose, language features, schemae, and implementation details. This file assumes a single-page spec, though it can be split into multiple pages * [http://dev.w3.org/SVG/modules/template/SVGTemplatePrimer.html SVG Template Primer]: this is a supplementary file, for providing usage examples, informative prose, rationalization for design decisions, and introductory material for authors. * [http://dev.w3.org/SVG/modules/template/SVGTemplateReqs.html SVG Template Use Cases and Requirements]: this is a supplementary file, for providing use cases and requirements for the main specification. It is strongly recommended to have one of these. ===Customizing Templates=== To reuse and customize the template for your own use, follow the following guidelines: * Create a new folder in the "[http://dev.w3.org/SVG/modules/ modules]" directory, with an appropriate short-name ("fonts", "filters", "layout", "integration", etc.) * Copy the desired files into a new directory. You only need to copy those files that you need (for example, you may not wish to have a primer yet, or you may wish to put the use cases and requirements directly in the main spec; note that in general, it is better to have a separate document for use cases and requirements, at least). Don't forget the stylesheets, if you need specific styles beyond those provided in the official W3C stylesheets. * Replace instances of the work "Template" or "&lt;em&gt;Template&lt;/em&gt;" with the short-name in the file names and in the document itself * Edit the document to contain at least an introduction, and as much content as you have available * Add and commit the new directory and files into CVS * Add a link to the file in the SVG WG wiki under [http://www.w3.org/Graphics/SVG/WG/wiki/Main_Page#Specifications Specifications], and a tentative timeline on the [http://www.w3.org/Graphics/SVG/WG/wiki/Main_Page#Roadmap Roadmap] * Email public-svg-wg (and maybe www-svg) that this is done, for broader review ==Build Scripts== Currently, the template is not hooked into the build scripts, because we haven't quite got them in place yet for modules. Therefore, handy things like automatic generation of a table of contents, automatic linking to definitions and such are not yet working. This is normaly fine for smaller specs, but quickly becomes unwieldy for larger specs, especially multi-page specs. ===Syntax=== When using the build script, you can use the shorthand notation &lt;a&gt;''term''&lt;/a&gt; in the spec to link element names, attribute names, interfaces, methods, keywords, terms, definitions, etc. to their canonical definitions. Here are some rough notes detailing usage: * if the type of references is ambiguous you can do &lt;a&gt;'mask element'&lt;/a&gt; or &lt;a&gt;'mask property'&lt;/a&gt; * if it's not ambiguous you can leave out the "element" or " property" bit * for attributes, if they're element-specific attributes, and in the definitions.xml you put &lt;attribute name="foo" elements="myElement" href="..."/&gt; * in the spec you can do: &lt;edit:with element="myElement"&gt; ... blah blah spec text &lt;/edit:with&gt;, so that the attributes for that element are "in scope" for the &lt;a&gt; lookup * for interfaces, you omit quotes, such as <a>InterfaceName</a> and <a>InterfaceName::memberName</a> * for small specs that only define one element, or don't have any clashing attributes, then you can leave out the elements="myElement" bit on the elt in definitions.xml ** this effectively means it's a global attribute, but it means you don't need to put that edit:with to get the &lt;a&gt; lookup working properly (for one off references, instead of &lt;edit:with&gt; you can do &lt;a&gt;'myElement/foo'&lt;/a&gt;)

Return to Creating a new spec.