[mapguide-internals] ForReview:MapguideRFC31-SymbolDefinitionSupportforEditControlsandRichTextSupport (Markup)

[Jason Nogar]

I agree that there would be added value in an (entirely optional) class
of additional metadata that could allow a symbol library creator to
specify the sort of values that are appropriate for the parameters in
their symbols.  Does this proposal really do much to empower those
library creators, though?  Is there really a UI difference when we are
selecting a TextColor versus a GhostColor versus a FrameLineColor? If we
had a parameter, say %TXT_COLOR% as the value of the <TextColor>
property, and %FRM_COLOR% as the value of <FrameLineColor>, those data
types would be appropriate.  But, as Traian pointed out below, what if I
have:
	
	<TextColor>%COLOR%</TEXTCOLOR>
	<FrameLineColor>%COLOR%</FrameLineColor>

I guess in this case I could use the type Color.  But why bother, when I
could have parsed the symbol definition and determined that %COLOR% is
used in color-type properties?  In the cases when the type
FrameLineColor would be appropriate, the parameter is used only in the
FrameLineColor property, something that is easy to check.

It was mentioned that one could use FillColor for a line color that is
actually used to color a hatch.  So...I guess this symbol has only an
AreaUsage and no other.  This data type isn't going be much help to the
UI when the symbol is being used to label points.  Even if the symbol
could be used in every possible context (lines, fills, points, etc.),
when the user was manipulating using Area Style UI, I think it would be
pretty clear (to the user and to the UI) that color was involved in area
stylization.

It seems to me that either the type of a parameter can be unambiguously
determined from the property in which it is used, or else it is used in
some sort of multi-property or expression argument context, and then no
data type can possibly fit except for the basics: String, Boolean, etc.
We might be able to deduce those types as well, but the types are often
very ambiguous. Consider: <FillColor>strcat(strcat(strcat(0xFF, %RED%),
%GREEN%), %BLUE%)</FillColor>.  The parameters here should all be
integers from 0-255.  But they should be formatted in hex, and will most
likely come from string properties in some feature class.  So should the
type be string?  That wouldn't be a very intelligent UI, but no other
type will even allow valid values.

Instead of trying to say that a parameter is for "RepeatX" or "RepeatY,"
the UI could act more intelligently from a list of basic data types (the
first six in the proposal) that represent valid input for the parameter,
and perhaps acceptable ranges and/or enumerations for each type.
Knowing that something is RepeatX will still not rule out all sort of
strange expressions that a user could concoct, but knowing that a value
is "Real", ">=10, <=15" would allow the UI to be quite specific, or
"String" [0-9A-F][0-9A-F] for the perverse example above.

Defining and parsing input masks could certainly grow into a rather
large job, so I am really advocating the addition of such metadata to
the schema (although it was something that was discussed around the time
the ParameterDefinition was defined), but I think that if we *do* decide
to add more metadata to empower the UI, encouraging symbol authors to
reiterate the name of the properties in which they use their parameters
is not the approach we should take.
	
Jason

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Thomas
M. Tuerke
Sent: Thursday, September 20, 2007 2:41 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals]
ForReview:MapguideRFC31-SymbolDefinitionSupportforEditControlsandRichTex
tSupport (Markup)

> I'd also hate to think that MapGuide would require someone to hire a
consultant in order to generate nice maps.

It's not certain that this is where symbolization is heading, but on the
other hand, I see libraries of open-source symbol definitions a very
real possibility out of this: collections of symbols that can be
described in such a way that the UI can intelligently interact with,
because this parameter is described as an angle, that a fill color, this
other one a line color, etc.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
Birch
Sent: Thursday, September 20, 2007 8:49 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] For
Review:MapguideRFC31-SymbolDefinitionSupport
forEditControlsandRichTextSupport (Markup)

Carsten wrote:
 
>The industry though thought we need a better, descriptive and parsable 
>way  of describing this content as a road. Redundant? Yes ... needed?
Yes ...
 
Do you have the same user-demand for the style metadata?  What are the
real-world use cases for this?  I can't pretend to understand the style
definition language, but I haven't typically seen this requirement for
visualization elements.
 
MapGuide is fast and powerful software, but it is also getting a
reputation for being large and complex.  I don't think that we want to
go the way of GML; massive functionality with relatively few users.  I'd
also hate to think that MapGuide would require someone to hire a
consultant in order to generate nice maps.
 
Jason
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals