Precision Graphics Markup Language (PGML) (original) (raw)

NOTE-PGML-19980410

World Wide Web Consortium Note 10-April-1998

This version:

http://www.w3.org/TR/1998/NOTE-PGML-19980410

Latest version:

http://www.w3.org/TR/1998/NOTE-PGML

Authors:

Nabeel Al-Shamma, Adobe Systems Incorporated

Robert Ayers, Adobe Systems Incorporated

Richard Cohn, Adobe Systems Incorporated

Jon Ferraiolo, Adobe Systems Incorporated

Martin Newell, Adobe Systems Incorporated

Roger K. de Bry, International Business Machines Corporation

Kevin McCluskey, Netscape Communications Corporation

Jerry Evans, Sun Microsystems, Inc.

Copyright 1998 Adobe Systems Incorporated. All rights reserved.

Status of this Document

This document is proposed to the World-Wide Web Consortium (W3C) as an initial draft. It is offered for review and comment by W3C members. This document is subject to change.

A list of current W3C Technical Reports, many of which are relevant to this proposal, can be found at: http://www.w3.org/TR/.

This NOTE is made available by the World Wide Web Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by this NOTE. A list of current NOTEs can be found at: http://www.w3.org/TR/.

This document is part of a complete submission to the W3C. The full submission has been acknowledged by W3C and is available athttp://www.w3.org/Submission/1998/06

1. Abstract

This document is the specification for the Precision Graphics Markup Language (PGML). PGML is a 2D scalable graphics language designed to meet both the simple vector graphics needs of casual users and the precision needs of graphics artists. PGML uses the imaging model common to the PostScript® language and Portable Document Format (PDF); it also contains additional features to satisfy the needs of Web applications.

2. Introduction

2.1 Status

This is a working document. It is not meant to be a complete definition for PGML. Many sections have been left open or have been labeled Ideas for Consideration so that the working group can develop the strongest possible language specification and ensure that it is fully compatible with other W3C standards efforts.

2.2 Purpose

This is a specification for the Precision Graphics Markup Language (PGML). PGML is a 2D graphics language meant to satisfy both the Web's scalable lightweight vector graphics needs and the precision needs of graphic artists who want to ensure that their graphic designs appear on end user systems with precisely the correct fonts, color, layout and compositing that they desire.

PGML uses the imaging model common to the PostScript® language[1] and Portable Document Format (PDF)[2]. In this document, this common imaging model will be called the PDF/PostScript imaging model.

2.3 Design Principles

The following design principles have been used to guide the development of PGML:

1. PGML should encompass the PDF/PostScript imaging model to guarantee a 2D scalable graphics capability that satisfies the needs of both both casual users and graphics professionals.
2. PGML should extend the PDF/PostScript imaging model to satisfy the graphics requirements of the Web, particularly in terms of transparency, anti-aliasing, the hooks for animation and dynamic behaviors.
3. PGML should be compatible with the needs of three types of Web page creators: those who want to hand-code their graphics using a text editor, those who want to generate graphics via client-side or server-side scripts, and those who want to create their graphics via a graphics authoring application.
4. Both inline PGML (i.e., embedded within an HTML stream) and external (i.e., via URL specification) PGML should be supported.
5. PGML and PGML processors should support progressive rendering.
6. PGML should be highly compressible to reduce download time for complicated drawings.
7. PGML should be scriptable.
8. PGML needs to conveniently support simple animations such as moving a collection of objects along a motion path, transforming a collection of objects over time and changing color and opacity over time. More sophisticated animations should be possible using scripting.
9. PGML should allow for the inclusion of private application data to enable PGML authoring applications to write then read PGML files without loss of high-level application data.
10. PGML should be an XML[3] application and the imaging model is an instance of the RDF[14] data model.
11. PGML should be compatible with and fully leverage all related W3C standards efforts.
12. PGML should be fully international.
13. Text in PGML graphics should be easily extractable by search engines and tools that aid accessibility to disabled people.

2.4 A Proven Imaging Model

PGML uses the imaging model of the PostScript language and PDF as its basis in order to provide simple-to-use graphical objects and precise visual fidelity.

This imaging model is lightweight yet robust, comprising a small number of object types, attributes and operators which can be easily leveraged to satisfy the most challenging 2D graphics needs. It is suitable for all graphics applications, from business charts and diagrams to CAD and publication-quality art. It satisfies the needs of both display applications and high-end printing. The graphic artists who build many of the most popular commercial Web sites are experienced users of PostScript-based drawing/illustration products (e.g., Adobe Illustrator, Corel Draw and Macromedia Freehand) and of PostScript-based page layout tools (e.g., Adobe PageMaker and Quark Xpress) and make considerable use of PDF in their workflow.

The PDF/PostScript imaging model has been the basis and model for many graphics systems, including PostScript language implementations in printers and PostScript display systems (e.g., NeWS, Display PostScript, ghostscript). The Macintosh OS (via QuickDraw GX), Windows (via GDI-32), various UNIX implementations (via DisplayPostScript), the Java™ programming language (via the Java 2D API) and PCL printers have all been moving in the direction of adding complete support for the PDF/PostScript imaging model.

2.5 Extensions to Satisfy the Needs of the Web

PGML extends the PDF/PostScript imaging model to add features needed for Web applications, such as transparency and anti-aliasing. Furthermore, PGML includes a simple animation component and an object model which provides the hooks necessary for sophisticated Web animation and other dynamic behaviors.

Not all graphics needs are sophisticated. To serve the needs of casual users and to improve the ability of PGML authoring applications to support save then read without data loss, PGML defines a set of simple graphics objects such as rectangles, circles, ovals and pie wedges.

2.6 Relationship to Other Web Standards

PGML is compatible to the fullest degree with the direction and specifics of other W3C standards efforts, such as HTML[4], XML[3], XSL[5], CSS[6], DOM[7] and RDF[14]. PGML is fully compatible with XML and is representable in RDF. This proposal calls for the PGML working group to work out the details of the PGML language definition to achieve the optimum compatibility and cross-standard leverage.

2.7 Relationship to the Java 2D API

The Java 2D API is a set of Java classes for advanced 2D graphics and imaging that is part of the Sun JDK 1.2[8].

The Java 2D API includes the complete PDF/PostScript imaging model together with additional features for Web applications (e.g., transparency and various extensibility features). While PGML certainly can be implemented separately from JDK 1.2, the Java 2D API does offers a potentially straightforward and cross-platform graphics engine on which to build an implementation of PGML.

The PGML working group needs to decide to what extent, if any, the PGML design should rely on the Java2D API's features and contraints.

3. PGML Features

3.1 Required Features to Achieve the PDF/PostScript Imaging Model

PGML is built upon the proven foundation of the PDF/PostScript imaging model. For the full definitions of the PostScript language and PDF, refer to the PostScript Language Reference Manual - Second Edition[1] and the Portable Document Format[2] Reference Manual (version 1.2). A summary of the components of this imaging model follows:

• There are three primitive object types: paths, text and raster images. All of these object types operate in a uniform manner; thus, all operations can be performed on all object types. For example, transformation and clipping operations apply to images and text as well as path data.
• Paths represent an outline of an object which is defined in terms of_moveto_ (set a new current point), lineto (draw a straight line), curveto (draw a cubic bezier curve) and closepath (draw a line to the start of the path) operations. Compound paths (i.e., a path with subpaths, each consisting of a single moveto followed by one or more lineto or curveto operations) are possible to allow effects such as "donut holes" in objects. Once defined, a path can be used to set a clipping region (future objects are clipped to the outline of the path), fill the path (i.e., paint the interior), and stroke the path (i.e., paint the outline). Clip and fill operations can use either the even-odd or non-zero winding rule. Stroke options include line width, user-defined dash patterns (with an optional initial phase offset) and the standard PDF controls for path termination and mitering.
• Text is specified as a character string, a font, a text transformation matrix and a set of other text attributes. The outlines of the text can be filled, stroked and/or used to establish a path just as if the outlines had been specified as 2D vector graphics.
• Arbitrary 2x3 nested transformation matrices allow for such operations as rotation, skewing, reflection, scaling and translation. The nesting of transformation matrices allows embedding other drawings within a parent drawing.
• Precision layout: A user coordinate system, expressed in either integer or floating point numbers, is mapped via a 2x3 transformation matrix onto a rectangular viewport. The viewport is defined in either: (1) an absolute world coordinate system, expressed in the default units of points (a point is 1/72 of an inch) which represent real-world spacing on a physical device or (2) a fitted coordinate system, whereby the user coordinates are mapped to the viewport and scaling to fit within that viewport (i.e., 72 default units are scaled to fit and thus do not necessary equal 1 inch on the screen).
• Precision color: There is an option for either CIE-based device-independent color (i.e.., Lab and Calibrated RGB) or ICC profile-based device independent color[10].
• Precision fonts: Some mechanism is available to ensure that the fonts used within a given file are always available when that file is rendered. (In the PostScript language and PDF, this is achieved by various strategies whereby the font, or a subset of it, is embedded inside the file.)

Appendix A contains a detailed chart which presents how the features described above correspond to the PostScript language, PDF and the proposed PGML syntax presented in this document.

3.2 Features Beyond the PDF/PostScript Imaging Model

PGML requires the following additional features to satisfy the needs of the Web:

• Full conformance and compatibility with other W3C standards efforts; in particular, PGML will be an application of XML.
• Transparency, including the ability to composite multiple objects together first and then composite the result into a background using a given opacity setting.
• Grouping and naming support. The grouping feature allows multiple graphic objects to be collected and operated on as a unit. Each group or individual graphic object can be assigned a name. The grouping feature needs to allow arbitrary nesting. The grouping and naming features are minimal requirements to achieve animation capability via a scripting language and provide the necessary hooks for built-in animation features. The name would be the handle by which the built-in animation component or the scripting language, via the DOM, would perform operations (such as rotation or translation) on elements of the image.
• Anti-aliasing of text and line art. Graphic artists need the ability to tell the PGML processor whether anti-aliasing should be on and off for particular elements.
• sRGB color space support[11].
• Links
• Exporting the imaging model to the DOM.
• The ability to achieve sophisticated 2D animations via scripting.
• Embedded scripts within PGML, similar to how the

  4.11 DOM

  PGML elements can be accessed and manipulated using the W3C Document Object Model (DOM) Specification for XML. The DOM can be used for interactive editing, animations and to apply programmatic transformations to a PGML document. The hierarchical nature of a PGML document is represented as a tree structure in the DOM. Modifications allowed on this structure include the addition and deletion of individual PGML elements or subtrees of elements, and attribute modifications for individual elements. For example, the following script rotates the contents of a given document by 90 degrees by introducing a new element with the appropriate transformation:

  4.12 Event handling

  Any , , , , or element can be assigned any of the following standard HTML event handlers:

  Mouse Events

  • onmousedown
  • onmouseup
  • onclick
  • ondblclick
  • onmouseover
  • onmousemove
  • onmouseout

  Keyboard Events

  • onkeydown
  • onkeypress
  • onkeyup

  State Change Events (only applicable to element)

  • onload
  • onunload

  Additionally, PGML's scripting engine needs to have the altKey,ctrlKey and shiftKey properties available.

  4.13 Extensibility

  PGML defines an extensibility mechanism that allows for custom paint servers (i.e., fill and stroke types), custom object servers (e.g., 3D lettering), custom color space servers (e.g., to allow for a CMYK color space) and filter effects. Filter effects allow specialized compositing and raster image effects. An example of a compositing filter would be a matte effect which would allow any graphic to be used as an imagemask or a transparency blend other than the default channel-by-channel transparency blend in the sRGB color space. An example of a raster image effect would be a dropshadow filter, which might add a dropshadow to any graphic.

  An extension of any type requires an element within the section of the element. The element gives an ID to the extension, indicates what type of extension it is (i.e., a scripting language function, a Java applet or an ActiveX control) and, if appropriate, the location of the extension. Note that a single can support multiple servers of multiple types.

  For each particular type of extension, there is a corresponding element that must be provided to register a given extension: , , and . Each of these elements provides a reference to the corresponding element and provides its own ID.

  Here is an example of the definition and use of a custom "3DLetters" object type and a custom "pointillize" paint server. The example draws the string "3DLettering!" (which has a 3D look) and then fills a rectangle with a pointillize pattern:

  (Late-breaking news - The issuance of the namespace note http://www.w3.org/TR/1998/WD-xml-names-19980327, along with the processing instructionfeatures in XML has opened up technical approaches that should fit in well with PGML's extensibility features and should replace the syntax shown above.)

  4.14 Description Attribute

  Each element in a PGML document can have an optional _description_attribute. The description attribute can contain any value and is ignored by the PGML processor. One of its possible uses is to describe in words the contents of the corresponding graphic elements in words to provide increased accessibility for the visually impaired.

  ---

  5: PGML Reference

  (Not yet written.)

  ---

  6: DOM Interface to PGML

  (Not yet written.)

  ---

  7: PGML Dependencies on CSS

  (Not yet written.)

  ---

  8: PGML Dependencies on Browsers

  (Not yet written. APIs for color management, getting imagedata from a URL, rasterizing fonts, DOM integration, scripting integration, printing, compression, an indication of the real physical size of the viewport, CSS integration, inherited current style information,...)

  ---

  Appendix A: Mapping PostScript Language and PDF Features to PGML

  Feature	Corresponding PostScript language commands	Corresponding PDF commands	Proposed PGML
  Specifying path data	- newpath x y moveto x y lineto x1 y1 x2 y2 x3 y3 curveto - closepath	- n x y _m x y _l x1 y1 x2 y2 x3 y3 _c - h	...
  Painting paths	- fill - eofill - stroke	- f - f* - S	fill="1" fillrule="nonzero" fill="1" fillrule="evenodd" stroke="1"
  Path attributes	array offset setdash linejoin setlinejoin linecap setlinecap miterlimit setmiterlimit linewidth setlinewidth	array phase d linejoin j linecap J miterlimit M linewidth w	dasharray= dashoffset= linejoin= linecap= miterlimit= linewidth= (These attributes can also be set via a corresponding STYLE attribute and via CSS.)
  Establishing a new clipping path	- clip - eoclip	- W - W*	clippath="xxx" fillrule="nonzero" clippath="xxx" fillrule="evenodd"
  Drawing image data	(manyparams)colorimage	- BI - ID - EI	<**img** ... /> (Matches img element in HTML.)
  Drawing text data	string show string as_how_	- BT string Tj array TJ - ET	<**text**>string<**/text**>
  Text attributes	ax ay string ashow font scale scalefont font setfont font matrix makefont ax ay string ashow proc string kshow	charspacing Tc fontname size Tf   matrix Tm textscale Tz rise Ts wordspacing Tw	charspacing= textsize= font= concat= textsize= textrise= wordspacing= (These attributes can also be set via CSS.)
  Using text outlines as paths	string bool charpath	7 Tr	<**text** **name="xxx">**string<**/text**> clippath="xxx"
  Embedded fonts	Achieved by including entire font definition within the PostScript stream.	Achieved by including glyph definitions within Font Descriptor	Use same strategy as CSS2 is proposing for embedded fonts, with includes the ability to specify a font via a URL.
  Save/restore graphics state	- save - restore	- q - Q	Achieved implicitly. Each new begin element/end element pair does an implict save and restore operation, respectively, on the graphics state.
  Transformation matrices	matrix concat sx sy scale angle rotate x y translate	matrix cm	concat=
  Grayscale and RGB color	gray setgray   r g b setrgbcolor	gray g gray G r g b rg r g b RG The lowercase comands above represent fill colors; the uppercase commands represent stroke colors.	fillcolor= strokecolor= (All grayscale and RGB colors represent the colors in the sRGB color space. These attributes can also be set via a corresponding STYLE attribute and via CSS.)
  CIE color	array setcolorspace The entries in the array specify the details of the device independent color space that will be used.	intent ri	fillcolorspace= strokecolorspace= colorrenderingintent= The default colorspace is sRGB. Other built-in colorspace options are CalRGB and Lab. All grayscale and RGB colors represent the colors in the sRGB color space. These attributes can also be set via a corresponding STYLE attribute and via CSS.

  ---

  Appendix B: PGML Samples

  ---

  Appendix C: Ideas for Consideration

  This section describes ideas on various features and/or designs which are presented for consideration and are expected to require considerable ensuing discussion and modification.

  C.1 Nesting PGML files

  A stream can contain elements anywhere within itself. This allows PGML authoring applications to "place" stand-alone PGML files as graphic objects within another drawing. The following example illustrates two embedded elements. The first one is a URL reference to an external PGML file. The second places the embedded inline:

  ... ... ...

  The PGML graphics engine treats embedded elements in the same manner as if the contained graphics had been specified within a element. (Note that it is still an open standards issue on how XML will be embedded within either HTML or XML.)

  C.2 Re-usable, Pre-defined Graphic Objects

  For performance and convenience reasons, it is desirable to define a graphic object outside the actual graphic display list and then refer to that graphic object within the graphic display list. Two applications are for re-usable graphic symbols and pattern fills.

  A re-usable graphic object is defined by a element within the element. The can contain any combination of path data, image data and text data within it. Here is an example of the definition of a four star graphic object. (See the discussion of the"pattern" paint serverbelow to see how to use this object to fill a rectangle with a pattern. The source of this example is the Portable Document Format Reference Manual Version 1.2 page 206):

  ...

  The element will draw the specified pre-defined graphic object. Here is an example:

  C.3 Paint Servers

  The concept of a "paint server" provides a generalized, extensible way to allow for fill and stroke methods beyond color. Three standard paint servers could be built into PGML: a "color" paint server (the default paint server, it just fills or strokes with a solid color), a "lineargradient" paint server and a "pattern" paint server. The current paint servers for fill and stroke are determined by the current value of attributes _fillpaintserver_and strokepaintserver in the graphics state. (See _Extensibility_below for related information.)

  C.3.1 The "color" paint server

  The color paint server is used by default. It fills/strokes using the solid colors specified in the attributes fillcolor and strokecolor, respectively. To illustrate the color paint server, the following example fills a triangle with blue and outlines it in red:

  C.3.2 The "lineargradient" paint server

  Linear gradients consist of a smooth color transitions along a vector from one color to another, possibly followed by additional transitions along the same vector to other colors.

  Linear gradients are specified within the element and are then referenced using fillpaintserver or strokepaintserver attributes. A linear gradient is defined by a element which contains elements within itself. Here is an example of the definition of a gradient that consists of a smooth transition from white-to-red-to-black followed by a rectangle that is filled with that gradient:

  The offset attribute indicates where the gradient stop should be placed on the gradient vector (see fillparams below), where a value of 0 corresponds to the start of the gradient vector and a value of 1 corresponds to the end of the gradient vector. The midoffset indicates where the midpoint color (i.e., the color which is halfway between the color of this gradient stop and the following gradient stop) should be located on the segment between this gradient stop and the following gradient stop, where a value of 0 corresponds to this gradient stop and a value of 1 corresponds to the next gradient stop (default value is .5). The color indicates what color to use.

  In the element shown above, the fillpaintserver attribute indicates that the "lineargradient" paint server should be used instead of the default "color" paint server. The fillname attribute gives the ID (i.e., the unique name) of the particular linear gradient which should be used. The fillparams attribute provides paint-server-specific values. In the case of linear gradients, fillparams consists of four values [x1 y1 x2 y2] which identify the start and end of the gradient vector , where a value of (0,0) corresponds to the lower left corner and (1,1) is the upper right corner of the object's bounding box. By default, the gradient vector goes from (0,0) to (1, 0).

  C.3.3 The "pattern" paint server

  The "pattern" paint server is used to fill or stroke an object using a pre-defined graphic object which is replicated ("tiled") at fixed intervals in x and y to cover the areas to be painted. To fill with a pattern, set fillpaintserver="pattern" and set fillname to the name of the graphic object which represents the pattern. To stroke with a pattern, set _strokepaintserver="pattern"_and set strokename to the name of the graphic object which represents the pattern. This example fills a rectangle with the "fourstar" pattern defined in the Re-usable, pre-defined graphic objects section above:

  C.4 Z-depth and Object Visibility Control

  The attributes depth and visibility are for use with animation applications.

  C.4.1 The depth attribute

  The depth attribute is a number which indicates the relative drawing order for that collection of graphics relative to other graphics with the same parent. depth is can only be set/changed via the DOM. (Any _depth_value within a PGML file will be ignored.) The default depth is 0.

  C.4.2 The visibility attribute

  The visibility attribute indicates whether a given object is visible or not. visibility can be changed via the DOM. The default value is "1", which indicates that the object is visible.

  C.5 Private Data

  Note: The issue of private data is currently an area of active discussion in the XML[3] working group. The proposal below should be considered one approach. PGML should deal with private data in the same way as all XML applications.

  PGML allows private data to be included virtually anywhere in the PGML content stream in order to to enable PGML authoring applications to write then read PGML files without loss of high-level application data. Nearly any element in PGML can contain a element and a element can contain any content (utilizing XML namespaces, of course). For example, a business graphics authoring application might want to include some private data within the section when it writes a PGML file so that it could properly reassemble the chart (a pie chart in this case) upon reading it back in:

  C.6 Compression

  The specification recognizes that compact data streams are a requirement on the Web but leaves the choice of compression scheme(s) as an open issue for the working group.

  Here are ideas for consideration regarding compression:

  • General compression schemes (e.g., using a Flate filter) that would work with any stream, including both HTML and PGML
  • A compression scheme on path data that is patterned after one of the methods used by font vendors to compress font data
  • A shorthand alternative syntax for ... which expresses the same information, is still readable but uses fewer characters

  C.7 Animation

  PGML needs to support dynamic graphics. Various features described above such as Grouping and Naming Collections of Drawing Elements and _Scripting_provide hooks that allow PGML to be driven via the DOM for dynamic effects. Additionally, it would be advantageous to many Web applications if commonly used simple animations (e.g, moving a collection of object along a motion path, transforming a collection of objects over time and changing the color and opacity over time) could be defined simply in PGML rather than forcing all animations to be done via scripting.

  Here is an example that illustrates how simple animation support might be incorporated into PGML. PGML can contain any number of elements that define dynamic behaviors:

  Note that the simple animation capability in the element described above does not allow for synchronizing an audio or video stream. Scripting will be needed to initiate other media types, enable scripts to start and stop animations and provide hooks to synchronize with other media types.

  ---

  Appendix D: PGML DTD

  ---

  Appendix E: References

  [1] "PostScript Language Reference Manual, Second Edition", Adobe Systems Incorportated, Addison-Wesley, Reading Mass., 1990. ISBN 0-201-10174-2.

  [2] "Portable Document Format Reference Manual", Adobe Systems Incorportated, Addison-Wesley, Reading Mass., 1993. ISBN 0-201-62628-4 describes PDF 1.0. See http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDFfor PDF 1.2.

  [3] "Extensible Markup Language (XML)", Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, W3C, November 1997. See http://www.w3.org/TR/WD-xml

  [4] "HTML", W3C Recommendation for HTML 4.0, December 1997, http://www.w3.org/TR.

  [5] "A Proposal for XSL", Sharon Adler et al, August 1997. See http://www.w3.org/TR/NOTE-XSL-970910

  [6] "Cascading Style Sheets, level 2 (CSS)", Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, W3C, November 1997. See http://www.w3.org/TR/WD-css2

  [7] "Document Object Model Specification", Lauren Wood, Jared Sorensen, Steve Byrne, Robert S. Sutor, W3C, October 1997. See http://www.w3.org/TR/WD-DOM

  [9] "Java 2D API", Sun Microsystems, Inc. See http://java.sun.com/products/java-media/2D/index.html

  [10] "International Color Consortium Profile Format Specification, version 3.4", International Color Consortium. See ftp://sgigate.sgi.com/pub/icc/ICC34.pdf. Also see http://www.color.org for an overview of the ICC.

  [11] "A Standard Default Color Space for the Internet - sRGB", Michael Stokes, Matthew Anderson, Srinivasan Chandrasekar, Ricardo Motta, W3C, Version 1.10, November 1996. See http://www.w3.org/Graphics/Color/sRGB.html

  [12] "The Unicode Standard: Version 2.0", The Unicode Consortium, Addison-Wesley Developers Press, 1996. The specification also takes into consideration the corrigenda at http://www.unicode.org/unicode/uni2errata/bidi.htm.
  For more information, consult the Unicode Consortium's home page at http://www.unicode.org/

  [13] "ECMA-262", ECMAScript: A general purpose cross-platform programming language, ECMA June 1997, http://www.ecma.ch/or helpdesk@ecma.ch

  [14]"Resource Description Framework (RDF) Model and Syntax", Ora Lassila, Ralph R. Swick, W3C, 16 Feb 1998. See http://www.w3.org/TR/WD-rdf-syntax/