W3C

SVG Referenced Parameter Variables 1.0, Part 2: Language

W3C

This version:
Latest version:
Editors:
Doug Schepers, W3C <schepers@w3.org>
Authors:
The authors of this specification are the participants of the W3C SVG Working Group.

Abstract

The Referenced Parameter Variables specification is an SVG 2.0 Module to provide a declarative way to incorporate parameter values into SVG content. Often, users may wish to create a single resource, and reuse it several times with specified variations, and this specification provides a means to do so without the use of script.

Although originally designed for use in SVG, some aspects of this specification are defined in XML and are accessed via presentation properties, and therefore could be used in other environments, such as HTML styled with CSS and XSL:FO.

This document defines the markup and interfaces used by SVG Referenced Parameter Variables.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document is the first public working draft of this specification. There is an accompanying SVG Referenced Parameter Variables 1.0, Part 1: Primer that lists the ways SVG Referenced Parameter Variables may be used.

This document has been produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.

We explicitly invite comments on this specification. Please send them to www-svg@w3.org (archives), the public email list for issues related to vector graphics on the Web. Acceptance of the archiving policy is requested automatically upon first post to either list. To subscribe to this list, please send an email to www-svg-request@w3.org with the word subscribe in the subject line.

The latest information regarding patent disclosures related to this document is available on the Web. As of this publication, the SVG Working Group are not aware of any royalty-bearing patents they believe to be essential to SVG.

Publication of this document does not imply endorsement by the W3C membership. A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Working Draft as anything other than a work in progress.


How to read this document and give feedback

This draft of SVG Referenced Parameter Variables introduces new Referenced Parameter Variables syntax and markup for the SVG language. One of the goals is that this specification can be re-used more easily by other specifications that want to have advanced Referenced Parameter Variables features. This specification introduces syntax that may not be backwards compatible with older SVG User Agents, and the use of this syntax should be accompanied by a fallback using the 'switch' element.

The main purpose of this document is to encourage public feedback. The best way to give feedback is by sending an email to www-svg@w3.org. Please include in the subject line of your message the string "[Params]", and a short keyword that identifies the area of the specification the comment is referring to (e.g "[Params] Section X.Y - Foo attribute values"). If you have comments on multiple areas of this document, then it is probably best to split those comments into multiple messages.

The public are welcome to comment on any aspect in this document, but there are a few areas in which the SVG Working Group are explicitly requesting feedback. These areas are noted in place within this document.

Table of Contents

Introduction

This specification describes a declarative syntax and associated interfaces to allow parameter values to be used directly in the content of the SVG file, without the need for script. These parameters may be provided to the document context through a variety of means, including, but not limited to, URL query strings or the 'param' element in the HTML 'object' element.

Access to these parameters is currently possible by the use of script, but this does not work in scenarios where script is undesirable or unavailable. Further, there is no general way to set and access all parameter inputs into the file, which may come from multiple sources. To address this, this specification defines an interface to provide a generic and secure means of passing parameters into a referenced file. This interface is intended to be implemented on all objects that implement the Window interface.

Note that even though this specification references parts of SVG 1.1 and SVG Tiny 1.2, it does not require a complete implementation of those specifications.

This document is normative.

This document contains explicit conformance criteria that overlap with some RNG definitions in requirements. If there is any conflict between the two, the explicit conformance criteria are the definitive reference.

Use Cases and Requirements

Usage Scenarios

The following usage scenarios illustrate some of the ways in which SVG Referenced Parameter Variabless might be used for various applications.

Adapt colors to fit theme

Color values can be passed into a graphic to match other aspects of the document. Note that in some scenarios, this can also be done via CSS.

Change size or position of graphical elements

In addition to making the whole image scalable by changing the 'viewBox', values can be passed in to change the size or position of particular elements as needed. For example, a dot on a map could be changed by merely passing in a parameter.

Hide or show elements

Particular elements of the image can be hidden or revealed based on parameters. Note that in some scenarios, this can also be done via CSS.

Adapt text to use

Labels on buttons or other reusable controls can be changed simply by setting the desired text as a parameter.

Change link locations

By passing in a URL as a parameter, links inside the SVG document can be changed, for ads or other purposes.

Special Considerations for Referenced Parameter Variables

Reuse: User Agents may fetch resources multiple times when the query string is different, once for each unique URL. This undermines some of the benefit of reusing resources: it does not take advantage of local caching, it increases the overall bandwidth, and it may introduce delay in slow or high-latency networks. Providing parameters through other means, such as the 'param's element, does not have the same drawback.

Memory and processor requirements: What are the requirements on memory or processing resources?

Implementation commitments: How difficult, or what details are needed, for implementation?

Ease of authoring: What considerations need to be borne in mind for authors?

Requirements

  1. General Requirements
    1. Conformance criteria for Referenced Parameter Variables must be produced. The criteria should be separated into sections relevant to particular application types (eg. SVG files/document fragments, SVG generators, SVG viewers, SVG printers, etc.)
    2. Software or documents must pass the relevant criteria to be able to claim conformance to the particular application type.
    3. A conformance test suite must be developed for Referenced Parameter Variables. The test suite must be made publicly available. Conformance test suites for other uses of Referenced Parameter Variables (e.g. prepress guidelines) may be developed.
  2. Scripting
  3. Animation

Definitions and Basic Data Types

This chapter defines a number of common data types used in the definitions of SVG properties and attributes.

Definitions

host language

A host language is a syntax which incorporates one or more SVG document fragments by inclusion or by reference, and which defines the interactions between document fragments; an example of this is WICD Core 1.0, an XML framework which defines how XHTML, SVG, MathML, XForms, SMIL, and other syntaxes interact [WICD].

in error

A value is in error if it is specifically stated as being "in error" or "an error" in the prose of this specification. See C.3 Error processing in SVG Tiny 1.2 for more detail on handling errors.

Invalid IRI reference

An invalid IRI reference is an IRI reference that is syntactically invalid, cannot be resolved to a resource or takes a form that is not allowed for a given attribute, as defined in SVG Tiny 1.2 14.1.4 Reference restrictions.

IRI reference

An IRI reference is an Internationalized Resource Identifier with an optional fragment identifier, as defined in Internationalized Resource Identifiers [RFC3987]. An IRI reference serves as a reference to a resource or (with a fragment identifier) to a secondary resource. See References in SVG Tiny 1.2 [SVGT12].

non-local IRI reference

A non-local IRI reference is an IRI reference that references a different document or an element within a different document.

rootmost 'svg' element

The rootmost 'svg' element is the furthest 'svg' ancestor element that does not exit an SVG context. See also SVG document fragment.

SVG context

An SVG context is a document fragment where all elements within the fragment must be subject to processing by an SVG user agent according to the rules in this specification.

If SVG content is embedded inline within parent XML (such as XHTML), the SVG context does not include the ancestors above the rootmost 'svg' element. If the SVG content contains any 'foreignObject' elements which in turn contain non-SVG content, the SVG context does not include the contents of the 'foreignObject' elements.

SVG document fragment

An SVG document fragment is the XML document sub-tree whose rootmost element is an 'svg' element (that is, the rootmost 'svg' element.)

An SVG document fragment consists of either a stand-alone SVG document, or a fragment of a parent XML document where the fragment is enclosed by the rootmost 'svg' element.

SVG user agent

An SVG user agent is a user agent that is able to retrieve and render SVG content.

unsupported value

An unsupported value is a value that does not conform to this specification, but is not specifically listed as being in error. See the Implementation Notes for more detail on processing unsupported values.

user agent

The general definition of a user agent is an application that retrieves and renders Web content, including text, graphics, sounds, video, images, and other content types. A user agent may require additional user agents that handle some types of content. For instance, a browser may run a separate program or plug-in to render sound or video. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers; used alone or in conjunction with assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software [UAAG].

A user agent may or may not have the ability to retrieve and render SVG content; however, an SVG user agent must be able to retrieve and render SVG content.

Basic Data Types

<Char>
A character, as defined by the Char production in Extensible Markup Language (XML) 1.0 ([XML10], section 2.2), or the Char production in Extensible Markup Language (XML) 1.1 ([XML11], section 2.2) if the document is an XML 1.1 document.
<FuncIRI>
Functional notation for an IRI: "url(" <IRI> ")".
<ID>
The type of value that can be used in an XML attribute of type ID; that is, a string matching the Name production in Extensible Markup Language (XML) 1.0 ([XML10], section 2.3), or the Name production in Extensible Markup Language (XML) 1.1 ([XML11], section 2.3) if the document is an XML 1.1 document.
<IDREF>
The type of value that can be used in an XML attribute of type IDREF (such as 'observer'); that is, a string matching the Name production in Extensible Markup Language (XML) 1.0 ([XML10], section 2.3), or the Name production in Extensible Markup Language (XML) 1.1 ([XML11], section 2.3) if the document is an XML 1.1 document.
<IRI>
An Internationalized Resource Identifier (see IRI).
<string>
A sequence of zero or more <Char>s.

The 'ref' element

Every 'ref' element has an associated value, which is determined based on the 'param' attribute and the set of name/value parameter pairs that are available for reference.

The 'ref' element shall act as both a paint server and a source of character data content for a referencing element, such as a 'tref' element. When acting as a paint server, the child character data content shall be treated as the value (as text) of the 'ref' element; this is unlike other paint servers, which provide the value of the paint as an attribute value, the 'ref' element. When acting as a source for a text reference, the value shall be the child character data content, as normal.

The value of the 'ref' element shall be derived from the value of the name/value pair whose name matches the value of the 'param' attribute, as accessed through the Parameters interface, and this value must replace any existing child character data content immediately upon the loading of the file, or whenever the parameter information becomes available. If the parameter information changes, all 'ref' elements and any referencing content must be updated to reflect the new values. If no parameter name exists that matches the value of the 'param' attribute, then the existing child character data content shall be the value of the 'ref' element. If the parameter information changes, and a the new information does not contain a name that was previously matched by the value of the 'param' attribute, then the existing child character data content shall reflect the existing content; it must not change back to the original child character data content. If the 'ref' element is an empty element, the lacuna value shall be an empty string.

The 'ref' element can also act as a mechanism to pass parameters to externally referenced resources, in a manner similar to the HTML 'param' element of the HTML 'object' element [HTML4]. In this case, the 'param' attribute must act as the 'name' portion of the name-value pair, and the child character data content must act as the 'value' portion of the name-value pair.

Attribute definitions:

id = <ID>

The 'id' attribute is the method by which attributes on other elements must reference this 'ref' element.

Animatable: yes.

param = <string>

The 'param' attribute must be a string that matches, in a case-sensitive manner, the 'name' portion of the name/value pair of the desired parameter.

Animatable: yes.

Applying the 'ref' element

This section needs a lot of work.

The 'ref' element shall be referenced in two ways:

In previous SVG specifications, only presentation attribute such as 'stroke', 'fill', or 'filter' could reference values via the <FuncIRI> syntax. This specification extends earlier attribute definitions to allow any attribute to reference content using a <FuncIRI>. The fragment identifier of the <FuncIRI> provides a link to the 'ref' element that shall be used to paint or provide the value for the current element. SVG user agents are only required to support local IRI references. If the IRI reference is invalid (for example, it points to an object that doesn't exist or the object is not a valid paint server or it is a non-local IRI reference and the viewer does not support it), then the fallback value (if specified) is used; otherwise it must be treated as if none was specified.

DOM interfaces

The interfaces below will be made available in a IDL file for an upcoming draft.

The following interfaces are defined below, using WebIDL [WebIDL]: Parameters.

Interface Parameters

The Parameters interface provides a unified API to access all parameters that have been passed into a file as name/value pairs, by whatever means, and independent of whether the file is a standalone resource or is embedded into another document by reference. The user agent must make all of these parameters which have been set at the load time of the target file immediately available, and must also update the list of parameters immediately within the file when they are changed in the referencing file, or in the URL query string.

Ordering of the parameters should follow document-order, in the case of HTML 'param' elements, SVG 'ref' elements, or similar constructs, and string-order in the case of URL query strings. In the case where duplicate names are provided that match in a case-sensitive manner, the corresponding later values must overwrite the corresponding earlier values, and values from the URL query string must be processed last, to overwrite all other values.

The Parameters interface must only handle name/value parameter sets which are string values. For parameters that are passed in via the HTML 'param' element, the user agent must add to this list only values which have the 'valuetype' of 'data'.

Objects that implement the defaultView or Window interfaces must also implement the WindowParameters interface:


WebIDL Definitions
interface WindowParameters {
  readonly Parameters parameters;
};
            

interface Parameters {
  readonly attribute unsigned long length;
  [IndexGetter] DOMString name (in unsigned long index);
  [NameGetter] DOMString getValue (in DOMString name);
};
            

Attributes
readonly unsigned long length
Indicates the number of name/value parameter sets available. The indices of the supported indexed properties are in a range whose lower bound shall be 0 and upper bound shall be n-1, where n is the number of name/value parameter sets. If there are no supported indexed properties, then length shall be 0.
Methods
[IndexGetter] name
Gets the name portion of the name/value parameter set, at index n.
Parameters
in unsigned long index: The index of the name, where the first item in the list must have an index of 0.
Return value
DOMString: The name at the indicated index in the list.
Exceptions
DOMException:
INDEX_SIZE_ERR: Raised if the index is negative or is greater than or equal to the number of entries in the list.
[NameGetter] getValue
Gets the value portion of the name/value parameter set corresponding to the given name. The names of the supported named properties on the Parameters object are the keys of each name/value pair currently present in the list associated with the object, as derived from the parameters.
Parameters
in DOMString name: The case-sensitive string that matches the name provided.
Return value
DOMString: The value associated with the given name, as provided in the parameters to this document. If no match for the given string is found, or no parameter is provided, the return value must be null.
Exceptions
none

This interface is read-only. Should there be a read-write interface available to the referencing document, to allow easy script access to parameters, so they can be changes without modifying the URL query string or creating 'param' elements?

Does allowing the author of the referencing document to override parameters defined in the URL strings constitute a security or propriety risk? What if a site serves a customized resource based on a URL string, and that is overridden at the param or script layer, so that what is served (think of an ad) is not what what intended by the SVG's content provider. Changing the URL in this case would let the content provider know, while changing the 'param's or modifying the parameters list through script would not. Is this a legitimate concern?

Should we expose where the parameter came from, in terms of URL query string, 'param' element, or other? Should we expose the domain of the document where the parameter was set?

RelaxNG Schema for SVG Referenced Parameter Variables 1.0

The RNG is under construction, and will be made available in an upcoming draft.

The schema for SVG Referenced Parameter Variables 1.0 is written in RelaxNG [RelaxNG], a namespace-aware schema language that uses the datatypes from XML Schema Part 2 [Schema2]. This allows namespaces and modularity to be much more naturally expressed than using DTD syntax. The RelaxNG schema for SVG Filter 1.2 may be imported by other RelaxNG schemas, or combined with other schemas in other languages into a multi-namespace, multi-grammar schema using Namespace-based Validation Dispatching Language [NVDL].

Unlike a DTD, the schema used for validation is not hardcoded into the document instance. There is no equivalent to the DOCTYPE declaration. Simply point your editor or other validation tool to the IRI of the schema (or your local cached copy, as you prefer).

References

Normative References

[HTML4]
HTML 4.01 Specification, D. Raggett, A. Le Hors, I. Jacobs. World Wide Web Consortium, 24 December 1999.
This edition of HTML 4 is http://www.w3.org/TR/1999/REC-html401-19991224/.
The latest edition of HTML 4 is available at http://www.w3.org/TR/html4/.
[RefPrimer]
SVG Referenced Parameter Variables 1.0, Part 1: Primer, D. Schepers, editor. World Wide Web Consortium, work in progress, 23 April 2009.
This edition of SVG Referenced Parameter Variables 1.0, Part 1: Primer is http://dev.w3.org/SVG/modules/ref/SVGRefPrimer.html.
The latest edition of SVG Referenced Parameter Variables 1.0, Part 1: Primer is available at http://dev.w3.org/SVG/modules/ref/SVGRefPrimer.html.
[RFC1738]
Uniform Resource Locators (URL), T. Berners-Lee, L. Masinter, M. McCahill, eds. December 1994.
Available at http://tools.ietf.org/html/rfc1738.
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997.
Available at http://tools.ietf.org/html/rfc2119.
[RFC3987]
Internationalized Resource Identifiers (IRIs), M. Dürst, M. Suignard, January 2005.
Available at http://tools.ietf.org/html/rfc3987.
[SVG11]
Scalable Vector Graphics (SVG) 1.1, J. Ferraiolo, 藤沢 淳 (Fujisawa Jun), D. Jackson, eds. World Wide Web Consortium, 14 January 2003.
This edition of SVG 1.1 is http://www.w3.org/TR/2003/REC-SVG11-20030114/.
The latest edition of SVG 1.1 is available at http://www.w3.org/TR/SVG11/.
[SVGT12]
Scalable Vector Graphics (SVG) Tiny 1.2, O. Andersson, R. Berjon, E. Dahlström, A. Emmons, J. Ferraiolo, A. Grasso, V. Hardy, S. Hayman, D. Jackson, C. Lilley, C. McCormack, A. Neumann, C. Northway, A. Quint, N. Ramani, D. Schepers, A. Shellshear, eds. World Wide Web Consortium, 22 December 2008.
This edition of SVG Tiny 1.2 is http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/.
The latest edition of SVG Tiny 1.2 is available at http://www.w3.org/TR/SVGTiny12/.
[WebIDL]
WebIDL, C. McCormack, ed. World Wide Web Consortium, work in progress, 19 December 2008.
This edition of WebIDL is http://www.w3.org/TR/2008/WD-WebIDL-20081219/.
The latest edition of WebIDL is available at http://dev.w3.org/2006/webapi/WebIDL/.
[XML10]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, eds. World Wide Web Consortium, 04 February 2004.
This edition of XML 1.0 is http://www.w3.org/TR/2006/REC-xml-20060816/.
The latest edition of XML 1.0 is available at http://www.w3.org/TR/REC-xml/.
[XML11]
Extensible Markup Language (XML) 1.1 (Second Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, J. Cowan, eds. World Wide Web Consortium, 15 April 2004.
This edition of XML 1.1 is http://www.w3.org/TR/2006/REC-xml11-20060816/.
The latest edition of XML 1.1 is available at http://www.w3.org/TR/xml11/.

Informative References

[HTML5]
HTML 5, I. Hickson, D. Hyatt, eds. World Wide Web Consortium, work in progress, 10 June 2008.
This edition of HTML 5 is http://www.w3.org/TR/2008/WD-html5-20080610/.
The latest edition of HTML 5 is available at http://www.w3.org/TR/html5/.
[NVDL]
Information Technology — Document Schema Definition Languages (DSDL) — Part 4: Namespace-based Validation Dispatching Language: ISO/IEC FDIS 19757-4:2005(E), International Organization for Standardization, December 2005.
Available at http://www.jtc1sc34.org/repository/0694.pdf.
[SCHEMA2]
XML Schema Part 2: Datatypes Second Edition. P. Biron, A. Malhotra, eds. World Wide Web Consortium, 28 October 2004. (See also Processing XML 1.1 documents with XML Schema 1.0 processors [XML11-SCHEMA].)
This edition of XML Schema Part 2 is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
The latest edition of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2/.
[WINDOW]
Window Object 1.0, I. Davis, M. Stachowiak, eds. World Wide Web Consortium, work in progress, 07 April 2006.
This edition of Window 1.0 is http://www.w3.org/TR/2006/WD-Window-20060407/.
The latest edition of Window 1.0 is available at http://www.w3.org/TR/Window/.

Acknowledgments

The editors would like to acknowledge and thank the following people for substantive aid with this specification: Erik Dahlström, Cameron McCormack, Jeff Schiller.