[mapguide-internals] RFC 14 (CartographicStylizationEngine) comments

[Ben Trumbore]

I would like to offer some comments/questions about this proposal.

SYMBOLIZATON SCHEMA - SIZES

I don't fully understand the way sizes are specified for ImageType
(SizeX and SizeY), PathType (LineWeight) and TextType (Height and
LineSpacing), as well as the assorted Position, Origin, Repeat,
BufferWidth and Offset parameters in the Usage elements.

Some of these values can be specified in mm or px, and some in just mm.
Are these values only used for relative sizing and positioning of
composite elements in a symbolization?  How are px values used with (or
converted to) mm values, or must they all be of the same type within an
element?  If px is meant to specify device-space sizes, how does it work
for devices with vastly different pixel sizes, such as monitors vs.
printers?  Why are units required hereat all?  Isn't it better to
specify sizes in the layer definition, as is done with the current
symbolizations?

If both mm and px are required in these elements, I am not comfortable
having the units merged with the value.  It makes it harder to create
the input values from layer properties, and the input values are forced
to be strings (see PARAMETERS, below).  Style editing UI and
symbolization processors must all parse the string to use it.  Could a
separate element specify the units, perhaps making it optional with a
default value of mm?

SYMBOLIZATON SCHEMA - PARAMETERS

I would like to see the parameter definitions include some type and
range information.  Passing everything as strings allows for expressions
to be used everywhere, which is great.  However, if the provided strings
can be parsed once and stored as known types in an object model, all the
code that uses the model can be simpler and faster.  Providing some
information about the parameter's expected type and range would support
such initialization.

It would also be very useful for any style editing UI that wants to set
those values.  Such UI could display the range and validate user
provided constants, or invoke the appropriate expression editor for the
required parameter type.  Types should include string, integer, real,
color, and possibly date/time.  Would we want to include a flag (and/or
possibly an optional length attribute) stating that the string
represented an array of values of the given type?

SYMBOLIZATON SCHEMA - DEPENDENT ELEMENTS

There are a number of elements in this schema that are only to be used
when another element has a certain value (search the doc for "only").
I'd like to see these become attributes of the element on which they
depend.  For example, there are several instances of Angle only being
used if AngleControl is set to FromAngle.  Instead of having an
AngleControl element with an enumerated set of values, we could use a
choice between two elements (FromGeometry and FromAngle) with FromAngle
having an Angle attribute.

LAYER DEFINITION SCHEMA - OVERPOSTING

It looks like the overposting parameters for a symbol have been moved
from the FeatureTypeStyle level into each individual SymbolInstance.
Was this intentional?  What happens when the symbols in a collection
specify different overposting values - do some parts of the composite
symbol sometimes disappear while others remain?  Must the values for all
symbols in a collection be the same?

Ben Trumbore
Autodesk