The modularization of SVG included here is a decomposition of SVG 1.0 and a small set of extra features into a collection of abstract modules that provide specific types of functionality. The modules are described in this specification and will be implemented by Document Type Definition and XML Schema in future drafts.

These modules may be combined with each other and with other modules to create SVG subset and extension document types that qualify as members of the SVG-family of document types.

Each major section of the SVG 1.0 specification produces a module named after that section, e.g. "Full Text Module". The term "Full" implies that the module includes the complete set of elements and attributes with no restrictions from the corresponding section of the specification. If there is need to provide a subset of the functionality in a Full module, then Basic and/or Tiny modules are created. A Tiny module is a subset of a Basic module which is a subset of a Full module.

It is an error for a profile of SVG 1.1 to include a module and a subset of that module (e.g. the Full Text Module and the Basic Text Module).

The modularization of SVG 1.1 allows profiles to be described by listing the SVG modules they allow and possibly a small number of restrictions or extensions on the elements provided by those modules.

The Full profile of SVG 1.1 is the collection of all the Full modules listed in this specification. Future drafts of this document will include a table that lists all elements, attributes and properties, along with the modules in which they are included.

When applied to conformance, the unqualified term "SVG" implies the Full profile of SVG 1.1 defined by this specification. If an implementation does not implement the Full profile, it must state either the profile to which it conforms, or that it implements a subset of SVG.

The svg element has an attribute version with a fixed value in SVG 1.0 . It is redefined in SVG 1.1 as follows:

In the situations where a DOCTYPE declaration is not available, SVG user agents require a method to identify the type of SVG content that the document fragment is using. The baseProfile attribute has been added to the svg element in SVG 1.1 to provide this information. Each profile of SVG is required to define a value to be used for the baseProfile attribute, preferably the name of the profile.

The Full Core Attribute Module defines the attribute set StdAttrs that is the core set of attributes that can be present on any element.

The Full Container Attribute Module defines the ContainerPresentationAttrs attribute set.

The Full Viewport Attribute Module defines the ViewportPresentationAttrs attribute set.

In order to allow interoperability between SVG content generators and user agents dealing with maps encoded in SVG, the SVG 1.1 specification encourages the use of a common metadata definition for describing the coordinate system used in the SVG files.

These metadata should be added under the metadata element of the topmost svg element describing the map. They consists of an RDF description of the Coordinate Reference System definition of the SVG map.

The definition should be conformant to the XML grammar described in the OpenGIS Recommendation on the Definition of Coordinate Reference System . In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the x-axis and the second axis maps the y-axis.

The main interest 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 then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems, then a specialised 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 recognise the metadata.

Below are two examples of the coordinate metadata.

The SVG Working Group considered adding the ability to allow graphical elements to be described using viewport coordinates into SVG 1.1. With this feature, graphical content such as toolbars or map legends could be statically placed within the user agent viewport and be unaffected by zoom and pan.

While the benefits of such a feature are obvious, the Working Group has decided to leave this feature out of SVG 1.1 and consider it for SVG 2.0. There are two reasons behind the decision: a substantial change to the rendering and coordinate system model is inappropriate for a minor update of the SVG specification and that the feature is difficult to describe and implement, and thus warrants heavy consideration to ensure the most appropriate solution is found.

The Full Style Module defines the StyleAttrs attribute set.

The Full Paint Attribute Module defines the PaintPresentationAttrs attribute set.

The Tiny Paint Attribute Module defines the PaintPresentationAttrs attribute set.

The Full Opacity Attribute Module defines the OpacityPresentationAttrs attribute set.

The Full Graphics Attribute Module defines the GraphicsPresentationAttrs attribute set.

The Tiny Graphics Attribute Module defines the GraphicsPresentationAttrs attribute set.

The Full XLink Attribute Module defines the XLinkRefAttrs attribute set.

The Full ExternalResourcesRequired Attribute Module defines the ExternalResourcesRequiredAttrs attribute set.

SVG 1.1 will deprecate the requiredFeatures and requiredExtensions attributes and replace them with requiredFeatureList. This attribute will allow boolean logic expressions based on XPath to allow greater control over conditional processing. There will be a mapping from the deprecated syntax to the new syntax.

The feature strings used SVG 1.1 will be URIs.

SVG 1.1 will include new elements to support simple text wrapping, as shown in the example below.

There will be seven new elements: tblock, region, regionRef, flow, p, span and br. All will be included in the Full Text Module and the Basic Text Module, but not the Tiny Text Module.

Each tblock has at least one region child to define the area in which text wrapping will occur. If multiple regions are defined, then once a region is filled the text will flow into the next region. The text to wrap is defined in the flow element.

The default user agent style sheet for SVG 1.1 will specify p as a block element, span as an inline element and br as a forced linebreak. When elements from arbitrary namespaces are inserted in a flow element, the content of those elements will be wrapped according to the value of their display property. The SVG user agent will position the text based on the properties, not the elements or their tag names.

The algorithm for line breaking will be very simple, basically breaking on spaces, zero-width spaces and Unicode soft hypens. If it is necessary to break a line that does not have any of these characters, then the line will break after the last character that fits. The algorithm will support multiline bidirectional text. The algorithm will produce identical results across implementations when the text is rendered with an SVG font.

The next version of this specification will include a element called solidColor that provides a paint server with a solid color fill at a specified opacity. This way, elements can reference a solid fill style in the same manner as used for the other paint servers, gradients and patterns.

The Tiny Color Module defines identical elements to the Full Color Module. It also defines the same value for the ColorElements content set.

The Full Document Events Attribute Module defines the DocumentEventsAttrs attribute set.

The Full Graphical Element Events Attribute Module defines the GraphicalElementEventsAttrs attribute set.

The Full Animation Events Attribute Module defines the AnimEventsAttrs attribute set.