Symbols, Markers and Pattern: One tag with three names?

The functions of symbols, markers and patterns is, distinct, but definitely
very similar. All these attributes reference reusable content. At the
moment, there are implementational differences between the three, but I
believe that there is no good reason to maintain that, and that further
more, it creates confusion about which element to use at which time and
limits flexibility by forcing the developer to specify in the SVG what the
use of a given symbol will be..

1. refX and refY
--------------------
I first propose that "refX" and "refY" become a part of the symbol element.
These two attributes would be a great help to cartographers, as well as
everyone else, and could perhaps be further explored ("refX='left'"?). If
refX and refY were available on <symbols>, the currently annoying process of
zooming and rotating around points other than the origin would be forgotten.


For a sample use case, (other than the currently self-evident use for
markers) consider the weather map demonstrated at SVG Open 2003 where
weather symbols could be scaled to improve visibility for impaired users. In
the demo, these symbols were scaled naively using the top left corner as the
reference point, causing them to lose their center -- the bigger they got,
the further they were from the actual points they were meant to represent.
If they had a refX and refY specified for their centers, they would have
expanded as expected. 

Also consider an animated car... If the center of the wheel symbol could be
used as the reference point, animating the rotation of the wheels becomes
much easier. It is true that these inconveniences can be got around using
complicated transforms and/or JavaScript -- but so can almost anything else.

2. orient
-----------------
When <marker> is eliminated, the functionality of the "orient" attribute
should be moved to the "%PresentationAttributes-Marker" set. Now users can
decide on a line by line basis whether they want their markers pointing a
certain direction.

3. markerWidth, and markerHeight (also pattern equivalents)
------------------
"markerWidth", and "markerHeight" are, in essence, the width and height
parts of a viewBox definition which assumes the x/y coordinates are (0,0). I
see no reason why the normal "viewBox" attribute could not take their place
on <symbol>.

4. markerUnits
----------------------
Could this be generalized? Should it be moved to symbol and left as is?
Should it be put into %PresentationAttributes-Marker? I am not sure about
this one. I haven't used it, particularly, but it looks like it makes
markers scale up or down with the stroke width.

5. markerClip (proposed)
---------------------
Discussing this with Chris Lilley, he mentioned that there was talk of
adding a "clip" attribute for things like tapering arrowheads, to prevent
the underlying line from peeping out around the edges. This could go into
%PresentationAttributes-Marker without any difficulty. Symbols already have
viewbox overflow properties, and maybe one of them could be hijacked to
provide this functionality?

6. pattern equivalences
---------------------------------
patternTransform -> could we just use the transform available on <symbol> or
is this because the transform on the symbol would result in creating
rectangular bounding boxes with gaps between them (after rotation or
skewing, or such), whereas transforming the _pattern_ happens after the
tiling takes place? It could go into &PA-Pattern, perhaps?

patternUnits -> I don't really see the use cases here, but I also don't see
why it couldn't be put into %PresentationAttributes-Pattern, for example.

X and Y could be handled by refX and refY, width and height, I'm not so sure
about.

Pattern might not be appropriate to fold into symbol, but I haven't been
using it so I thought I would mention it and see what kind of reaction I
got.

7. Conclusion
---------------------------------
Combining marker and symbol into one element would be relatively simple, and
provide some immediate functionality enhancements, as well as reducing the
overall size of the spec (thus improving the power to ink ratio). Marker's
attributes can be divided up between attributes that fit onto the symbol
definition and attributes that can be specified where the marker is used.
Pattern has some initial promise in being further reduced into a symbol, but
it does not immediately seem obvious how to finish the job.

If these three elements could become one element, it would improve
reusability and modularity very nicely.

Sincerely,
Peter van Hardenberg
Institute of Ocean Sciences
Victoria, BC, Canada