SVG Working Group (WG) has demonstrated considerable willingness to collect input from the community about the sorts of features that the language should contain to best support the needs of its user community. Like its cousin, HTML, SVG has a most remarkably divergent set of user needs. Given its emphasis on material displayed on planar devices, and given the intrinsic importance of spatial relations in the presentation of content using a spatial metaphor, SVG's user community may be expected to grow to embrace and support more diversity even than HTML, which at its core is (with the exception of the <table> element and possibly other elements related to spatial arrangement) 1.5 dimensional: that is, its fundamental metaphor consists of written speech (text), with occasional embedded belches of multimedia (<object>, <img>, <audio>, <video>) plus graph theoretic cross-references that provide a modest foray into translinearity.

For alphabet A={a₁, a₂, ... , a_n } and graphics G={G₁, G₂, ...G_k} (where A intersect G is empty)

The text -- a linear sequence of characters with occasional pictures.

For vocabulary V={w₁, w₂, ... , w_n }, including graphics G and anaphora H={h₁, h₂, ...h_k}  (where  G and H are subsets of V). An example of anaphora might include H={this, that, which, he, her}

The hypertext -- words and pix in sequence with references.

SVG has every bit as much semantic and pragmatic reference to meaning as HTML, it is every bit as hypertextual, but its core metaphor for expression is the plane rather than the line. As such it has come to attract, already, artists, physical and social scientists, and mathematicians whose needs for expression transcend the ability to belch static frames generated elsewhere into an otherwise translinear stream of text. For this community, multidimensional space is not the occasional 2D painting on the wall of an otherwise 1.5 dimensional hypertext, rather for n>=2, n- dimensional space is home.

In addition to being quite close to wrapping up one specification, the WG has been working hard on another and has announced both that it is focusing some of its efforts into extensions of the spec into focused areas of initiative (such as filters, gradients, transforms, accessibility, etc.) and that it is interested in engaging the community in broader dialogue about its needs. In response to community feedback it is already planning to consider extensions into non-affine transformations, richer sets of filter primitives, and improved control over layout and flow.

At the same time, it is important for the SVG community to respect the facts that a) standards development is hard work involving intense amounts of behind-the-scenes work with validation, test suites, conformance and other magical things I don't pretend to understand b) the WG already has a large agenda mandated by the standards process and c) there are not that many individuals in the WG to be able to do all the work already present. In part, this is why the SVG-IG has come into existence: to help with the workload (and hopefully, to shrink it at least as much as we add to it.)

So, without appearing to dump a giant chunk of work onto the WG*, I'd like to suggest that we have some discussions about new classes of effects for the SVG spec, under a couple of provisos: 1. let's realize that these are not responses to a candidate or current draft and 2) spec writers usually prefer it[1] when users structure the discussion of needs in a vocabulary and syntax that spec writers themselves use: use cases, disambiguation, validation, ontologies, and so forth. That is, if we can make our needs clear, document how or why the current spec doesn't do something, provide multiple situations (use cases) in which the feature could be useful (to the arts or sciences -- while recognizing that usefulness can mean very different things to different communities) , and perhaps, even suggest how the syntax of the feature might be expressed, then in such a case, the IG might reach consensus that a given feature be recommended to the WG for inclusion in "a future spec." The reason for saying "a future spec" is that, as I understand it, the W3C requires rather extensive amounts of work from a WG depending on the stage at which a given current spec is in its progression from draft to recommendation. I don't believe it would be in anyone's interest to derail any progress currently underway. We like SVG!

Some Suggestions:

I will discuss the following: the <contour>, an object consisting of concentric subpaths (closed curves) that instructs the gadget-browser[2] to interpolate those subpaths into something resembling a path filled with a gradient that is considerably more flexible than the radial or linear gradients, applied as effects.

A syntactically similar notion is the <superpath>. Like the <contour> it has <path> elements within it, but those path elements are never closed by z in their "d" attribute and represent the different borders that a given region might share with its neighbors (as in a geopolitical map). It is likely to be used both for map processing, graph theoretic purposes (like diagramming), animation, and for layout (that is more flexible than the HTML table or its CSS counterparts since it affiliates regions, connections and boundaries of arbitrary partitions of the plane)..

Also included (with increasingly less clarity in my mind as to exactly how they would work are the doodle, the editable attribute for <path>s and for certain <animate>s, the editable <sound> and the fractal (is it a basic shape or is it a filter?).

Speaking of filters, I believe the universe of possible filters (like the class of permutations of strings) is a large set. While, we might observe that a small number of primitives may suffice to generate all expressions in that expressive realm[3] I am not clear how best to optimize the size of that set, and to make matters worse, I think the boundary between filters and transforms occasionally becomes blurry -- perhaps because of Photoshop's inclusion of "distort" options in the fillter menu while simpler transforms live in the edit menu. Given the already rather high learning curve (so It would seem based on the expertise level of the audience that might show up for a workshop on filters) associated with filters, I think we should exercise caution about expanding that set too quickly. I am reminded of how quickly Kai's Power Tools became accessible as Photoshop plugins In the 1980's so we may wish to consider extensible grammars in this area. Nevertheless, I have three things to say on this topic: spherize and pinch (as either transforms or filters) are quite handy (owing to their relationship to common lenses) and a mechanism for weaving pictures together as in http://srufaculty.sru.edu/david.dailey/javascript/weave/weaframe2.html could prove useful both in artistic and cryptological communities[4]. Last and foremost it'd be nice to have a filter to convert bitmaps to paths like apparently happens in the diffusion curves video at http://www.youtube.com/watch . The fellow from Los Alamos at SVG Open 2007 was doing pretty cool stuff with SVG and realtime data processing of scenes -- his algorithms were quite fast though USDOE has gotten rather stuck with cost recovery lately so I don't know if the stuff is still covered by the "works of the US govt / copyright" proviso. If nothing else the stuff that Adobe was doing in its early Illustrator (88) and the stuff in Inkscape (which is pretty darn sophisticated) and NIH image would give us an ample start in that direction.

The <doodle> is a somewhat declarative alternative to the <path>. Rather than drawing it by enumerating coordinates and transitions as in its simpler cousin <path>, one enumerates coordinates and transitions,but also extrapolations, iterations and simple enumerated, conditional and recursive operations.

It and the others will be discussed in more detail now.

A. The new grouping elements: <contour> and <superpath>

Basically, the contour and the superpath are like groups <g>, but all the visible elements inside are <paths>. Each gives explicit instructions to how those objects inside are combined, extrapolated, animated on the screen and how they are processed through certain JavaScript (or other language) calls. (I know the Spec refers to ECMAscript rather than JavaScript but ours is, after all, not a standards group and it is probably best to keep a sense of informality, and even, occasional humor to our discussions.)

B. The <contour>

As mentioned earlier, <contour> is an object consisting typically of concentric subpaths (closed curves). It interpolates those subpaths into something resembling a single path filled with a gradient that is considerably more flexible than the radial or linear gradients, applied as effects. It is like a contour map, but since the border (stroke) is not required, it resembles, when the curves are concentric, a shape gradient that may have multiple shapes inside. I had started writing this up before I had a chance to look at the stuff that we heard about concerning Diffusion curves, so I don't know how the two ideas compare. This idea is straightforward to implement and would rely on some code the browser implementers have probably already built (like following movement along a path). So with that in mind, here goes:

The paths within < contour > are constrained as follows:

Their fill must be either a simple color or a gradient (no patterns or filters). If two fills of type gradient are adjacent (in markup) then both must be of the same type (radial or linear). If two gradients of different type are adjacent then one must be of the null type (e.g. a simple fill=color) so as to allow a nonambiguous interpolation.

Typical syntax:

< contour type=null|gradient|animate path=”url(#q)” 
method=uniform|equidistant steps=positive-integer>

<path/>
<path />

.

.

.

<path/> 

</ contour >

Examples:

The way it works is this.In the default case, we build a shape by interpolating between two other shapes as in Illustrator (circa 1988) when you'd tween between two bezier curves. The tweening lays down, in sequence a series (of size "steps") of new path elements moving from the background to the foreground. Those path elements are rendered on screen, and inserted into the DOM., so that the <contour> expands the DOM declaratively. Inkscape provides this functionality under "effects" / "generate from path" which one can experiment with easily. Illustrator provides it under Object / Blend.

By default the interpolation moves the bounding box of the first to the bounding box of the last (with possible intermediate steps given by the path elements between first and last) with linear interpolation. If a path attribute is provided then the position of the center of the bounding box of the hypothetical curves will follow that curve. If the curve provided does not coincide with the bBox centers of paths that lie between the first and last, then the locus of those intermediate paths is overwritten by the path of the provided url. [I'm not sure I wrote this correctly, but I'm thinking of something much like the way SMIL animation follows a curve]

If the type specified is "gradient" then the <contour> itself may be used to shade any other simple drawn object in much the way that a radial gradient whose centroid and fx cause out-of-bounds regions. In such case, the <contour> is not rendered, and instead acts like it is part of a <defs> tag.

If the type specified is "animate" then the intermediate frames will not be added to the DOM nor accumulated on screen as rendered, but rather will be "moved" from the first position to the last following the "path" and interpolating shape and fill from beginnng to end (with the each specified path acting as a sort of intermediate keystop).

If the number of control points in each path is identical, then the tweening happens on the natural correspondence. Otherwise if one shape has n control points and the other m<n. then the mapping happens between the division of n into M subpaths of equal length (as measured by the same algorithms that give us path.getPointAtLength ).

Use cases:

1. creating simple 3D-looking objects with shading

2. allowing a richer class of gradients than just linear and radial (useful for drawing)

3. allowing a richer class of declarative animation in which two shapes and a path determine the framewise transitions as well as the 2-D path.

C. The <superpath> (including <map> and <node>)

Currently, any concept of "proximity" or adjacency (as in regions that share a border) within SVG must be defined using script. It is the premise of this proposal, that allowing markup to convey the sense of a spatial relation between two SVG objects is not only useful, but applicable to several areas, and ultimately liberating to programmer and non-programmer alike.

This is used to either facilitate animation of separate parts of an object, to easily define a class of part-whole relations, or to define a sequence of boundaries that define regions, as in a map, or tabular layout. We introduce the "superpath": that is, the union of a series of subpaths, in which those subpaths may, in fact, be shared between multiple ("contiguous") superpaths.  The one-dimensional junction of two superpaths converge is their border, and is typically, a <path> consisting of exactly one "M" subcommand.

The zero-dimensional junctions, or point, where three or more superpaths converge is called a "node". A collection of superpaths is called a map. The incidence matrix  (or boundary matrix or adjacency matrix)  of a <map> is uniquely specified by the pairs of <superpath>s  within the map that have shared subpaths.

Typical syntax:

<superpath  fill=color|gradient|pattern|filter>

<path/><path/>

<path /><node id=quotedstring /><path />

.

.

.

<path/><path/>

< node /> 

</superpath>

1. A <path> element in a superpath must not have a "z" path command at the end of its "d" attribute; it is not a closed path.

2. The <node> objects are for reference to the vertex shared by any two consecutive paths within the superpath.

3. by default, a <map> is of type "map"

4. I've decided it is easier to have the <map> element than to have a class of superpaths that contain superpaths. (my reasoning here is rather fuzzy)

5. a <node> at the end of the sequence of subpaths within

Superpaths allow for condensation of the data needed to specify a planar map or for the planar embeddings of graphs (whether intrinsically planar or not).

Several superpaths together in a collection are called a <map> which is either of type "map" or type "graph".

<map type=map|graph><superpath><path/><path/></superpath><superpath><path/><path/></superpath></map>

might be a typical usage.

Consider the following diagram that shows three planar regions drawn next to each other. At one level of zoom and data precision. the regions appear to abut one anotherr properly, but at another level we see that the imprecision (due to level of accuracy) has sundered the images from one another

.

The superpath works by breaking each region into a series of subpaths -- each describing the border where precisely two regions meet. A subpath is either a <path> or a <node>: a path containing only one x-y coordinate.

Let's begin with an example:

The above map could be described as

Note: any fills associated with paths that are part of a subpath are ignored, though their strokes might not be (since different borders between regions may require differing strokes. If a superpath region defines a stroke, then all subpaths inherit that stroke unless they have their own stroke defined.

Given two consecutively defined paths within a superpath, It is generally assumed that the last point of one, A(n) will be the first point of the next, B(1). If not there are two options: either a line segment is added connecting A(n) to B(1) prior to rendering, or a <point> element is inserted between the two paths to specify the nature of the transition between the subpaths it connects:

The above would instruct the browser to find a “smoothest” transition between the two paths – one which matches the slope of the two paths at the endpoints being joined. This involves definition of the <node> element, which for now is rather vague, but its purpose is to allow styles to be assigned to the juncture of two path segments, to give simplified control over animations of <superpaths> by animating the locus of such <node>s and to allow the identification of graph theoretic “nodes” when the superpath is of type =“graph”

When, for the map containing a collection of superpaths, type="graph" the concentration is on the linking structure provided between nodes or points. In the above diagram, the graph defined, would be the geometric dual of the map, so that this map (informally used to mean a group of superpaths) would in fact define the graph K4 (4 nodes all connected pairwise).

When we fill a superpath not with a color or fill, but rather with svg, what I mean by that is that we flow a given group <g> into the shape defined by that region. This allows a very flexible class of geometric layouts in the plane -- far more flexible and fine-grained I think that html <table> and far more user friendly than CSS when it comes to actually building something (empirical hypothesis demanding human factors data!)

Use cases/ rationale:

1. Allowing the author and user to zoom in on borders of regions of maps without having to specify huge levels of precision when the we zoom to close levels of details and still have regions borders zoom accurately. The presentation by Li, Yan (School of Computer, South China Normal University) "An Extension of Spatial Functionality for SVG Specification" at SVG Open 2008 made a fairly compelling use case. By way of extending this functionality for cartographic purposes, see also the footnote (a) that follows this section on making text disappear declaratively as we zoom out.

2. Allowing the data reduction afforded by not having to redundantly ship entire descriptors of regions which share common borders

3. Enabling methods which might deform one border of two shapes without having to redraw the entire map.

4. Enabling ease of animation by providing markup-based parsing of a drawn object into semantically relevant subobjects and maintaining the relational structure of those subobjects. We may, for example, by breaking a paths d that has 1000 elements into 100 subpaths of 10 control points apiece, we may animate just the "arm" subpath of a cartoon character, without having to interpolate between two 1000 point paths. This will likely make life easier for hand-coders and authoring tools alike.

5. Providing a lightweight format for the specification of binary relational data: graphs. The stipulation of the <node> object should be fleshed out but one can consider that by defaullt an entire group of superpaths would inherit

6. Providing a flexible method for stating the spatial relations between collections of SVG objects, that can be used to support layouts. One can imagine "pouring" GIS data into the <superpath>'s of a <map> under certain constraints about importance / display, edging, etc. More on this topic can be found in this note**

7. Providing scripting methods appropriate to the support of the above use cases.

Example A=getElementsById("Q") ///where Q is a group of superpaths

///can be followed by

Graph=A.toGraph()

///for the above example which would return a JavaScript object

Graph = [

]

That is, an incidence array for the nodes of the graph (which is sufficient for all relational data). If the geometry of the paths is relevant then

Graph=A.toGraph("lines") might return an object consisting of an array of node incidences together with an array of pointers to the actual subpath objects in DOM.

Footnotes

(a) On allowing text to scale "properly" at several layers of zoom.

For the cartographer, textual information (like letters and symbols in languages like English or Chinese) do not always scale properly.

 At one level of zoom (for example a view of northeastern China) we may only be able to see Beijing, Shijuiazhuang, Tianjin and Huhehaote displayed because of the minimum size required for the characters to be legible and the size of the map. At another level we may see Lanqfang, Tangshan, and Zhangjiakou as well. Still closer we may see the districts Fangshan, Shunyi and Changping.

The ability to describe this through markup rather than script, it seems to me, is desirable.

Something like <text zoomdetail="5">Changping</text> and <text zoomdetail="1">Beijing</text> would allow the browser to "know" at what levels of zoom, these labels should appear and at what levels they should remain invisible. This is not difficult to do with script, but a very large part of the charm of SVG is that it allows many such details to be handled by markup rather than script.

Building paths declaratively: the <doodle>

(See also the <replicate> below).
My thought here is based on the simple observation that it is too much work to have to actually write or draw all the coordinates in the d attribute of a path. Can't we do that declaratively by saying something like this?:

Walk south for three blocks, turn 20 degrees, repeat this operation 12 times, but reducing the scale each time by 20% as we go. This generates a spiral.

I remember writing a paper in grad school about the syntax of such declarative drawing languages (there were a couple at the time -- maybe Herb Simon (H. A. Simon, “Complexity and the Representation of Patterned Sequences of Symbols,” Psychological. Review 79 (1972):)  and later Seymore Papert defined one as I recall in Logo). My recollection of what I concluded is that isolation of the primitives was subjective and that no objective work on which of several distinct axiomatizations actually worked best for humans had been done. The progress in empirical work in such heavily theoretic areas has I suspect been largely neglected by researchers who would rather build things than study humans. However there are a class of smooth planar four regular graphs that as neural networks are sufficient to drive computation in two space (with only a trit of memory per processor) and the drawing of those graphs would be awfully nice if it could be done somewhat declaratively.

Consider something so simple as a regular octagon. And suppose we wish to do such through markup.

d="M 100 100 L 200  100  270.7 170.7 270.7 270.7 
     200 341.4 100 341.4  29.3 270.7  29.3 170.7 z" 

would be the way. (Note the presence of the irrational numbers in any embedding of the octagon in the Cartesian plane.)

Wouldn't " M 0 0 (Move forward 100 units turn right 45 degrees) repeat 8 z" is a much simpler construction for programmer or non programmer alike than to actually calculate the irrational coordinate positions.

I note that Inkscape's "effects" menu has a lot of the sorts of things I may be thinking of here. A simple microformat (is that the right word?) could be developed that would be easy to implement and would expand the expressive power of mathematicians, artists and animators alike.

<doodle dd="(((M 100 100 radian 330 12) scale .5) iterate 12) (((last duplicate) translate 30) rotate 20 ) iterate 5 >

Basically, it'd be sort of like the use of <use> in http://srufaculty.sru.edu/david.dailey/svg/ovaling.svg but defined on parts of curves rather than objects.

The primitive operations should include rotate, translate, scale, but also reflect (invert the markup point sequence description from left to right), fragment (shake or permute a given sequence), randomize, smooth and fractalize (to a given degree). The ability to insert random numbers into our SVG without script is likely to be very important, I think, to the arts community.

<replicate> : like SMIL only with space instead of time. See http://lists.w3.org/Archives/Public/public-svg-ig/2008JulSep/0109.html for my original description. Here is a brief synopsis:

Just as

<object><animate attributename1 propertylist><animate attributename2 propertylist></object>

succeeds in modifying <object> over time according to the attributes named in its child animations,

how about

<object><replicate attributename1 propertylist><replicate attributename2 propertylist></object>

that would lay out copies of <object> on a page? The number of copies and their positions and attributes would be determined by the property lists (including keyTimes which now becomes keyPlaces?) associated with each attribute.
 

Many folks have called for SVG to adopt editable text objects (like textareas). SVG 1.2 full has those, and Opera has already implemented editable text in SVG. The flowing text shapes are coming as well. Basically we want users to have a way to enter and modify strings In SVG.

Well it just makes sense since it is a graphic language that we should allow run time editing of shapes as well.

Any shape marked as editable, should be for the beginning selectable, repositionable, scalable, rotatable and annotatable. The interface for doing this is pretty common from application to applications these days -- Inkscape and some other open software projects are useable and probably available for adoption.

Click on an object -- its boundary becomes highlighted and handles appear. While selected if the mouse is over the object the second click signals the beginning a drag. A click on a handle signals the beginning of a resize, a click outside all of these (but within some radius) signals a rotation. While selected, the delete key remove from DOM.

Just as text folks want to be able to edit text without lots of script, graphics folks probably want to be able to edit graphics without a lot of script. This is SVG, of course.

Ditto all the above arguments for sound. It'd be relatively easy to build in a little SVG sound studio for all embedded sounds, so why not we do it?

Since the ordinal number of the specs currently under various states of juvenescense are all (to my knowledge) less than 1.3, how about we entitle (in an informal way, appropriate perhaps to an interest group that is not a working group) all such speculative specifications "speculafications" and let us adopt (again in the most informal of ways) an ordinal number for the union of all current speculafications to be equal to the next integer above the current Spec[5] minus an infinitesimal. In this case since the current Spec number is greater than 1 but less than 2, then all such speculations the IG discusses would be labeled SVG1.9999... **[6] At some point in time we might ask the SVG WG to recommend to some committee on committees (a WGWG?) that the official Spec never be numbered with an integer minus an infinitesimal, since that entire countable set of individually infinite strings would be reserved for speculifications.

(Doug, can I have an action item # for resolving the discussion of whether our group's discussion of specs should have a number?)

I conclude with some of my own examples at the end of my recent paper and at the end of my book. Some of these I've talked about already (but some I did not)[7]: