[mapguide-internals] For Review : Mapguide RFC31-SymbolDefinition
Support for Edit Controls andRichTextSupport (Markup)
Carsten Hess
carsten.hess at autodesk.com
Thu Sep 20 01:58:41 EDT 2007
Hi,
At first glance I agree with Traian that there is duplicate information. Though to me the duplication is not in the actual data type, it is in the whole parameter definition section. In fact this whole section in the xml is not needed to render and handle parameters right inside of MapGuide. The parameters themselves can be extracted from the rest of the symbol xml content. In fact, last I looked at the code (which is a while back though) I don't think the engine inside MapGuide uses the information in those parameter definitions at all. The symbols will work whether you define parameter definitions or not in the symbol xml. Personally I think this is the correct behavior.
The reason we proposed to introduce the parameter definition section in the XML was to support user friendly semantic information about parameters for possible applications that help manage and setup maps using symbols. For example the display name is a more user friendly version of the parameter name - really though it does not contain any real new information that is needed by the symbol.
To me this is like Metadata (e.g. FGDC, or ISO): Not really needed but really useful when looking at the actual data (the parameter). It gives me more detailed information about what the parameter really is representing.
Now to your example: Consider a circle filled with a dense cross hatch. In the CAD world hatches are nothing than lines - and in fact even in our symbols we allow vector fills. The line color of these linear geometries in the context of the symbol from a users point are a "Fill Color".. So semantically there is a difference whether something is a fill color or a line color - it is not just a color. From a data point of view so I agree with Traian: It is just a color...
Now looking at the list of new types proposed, I again agree that there are types there that we really don't necessarily need. For those types I can't find an example of semantic difference like the color. Said that, I still would keep those for completeness ... It just would be weird to say we give semantic data type info for some parameter types and not for others.
Anyways, to summarize: The data type element in the parameter definition does not describe a syntactical data type but rather gives semantic data type information. The whole parameter definition is metadata about the actual parameter.
By the way, I would argue that calling it data type may have not been our smartest naming decision and if we wouldn't have already shipped a version of MapGuide with this schema I would suggest a renaming of the tag as one can argue that the name is misleading. Of course, I don't have a better suggestion for a name you either :-)
Cheers,
Carsten
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org on behalf of Vishal Bangia
Sent: Wed 9/19/2007 16:57
To: MapGuide Internals Mail List
Cc:
Subject: RE: [mapguide-internals] For Review : Mapguide RFC31-SymbolDefinition Support for Edit Controls andRichTextSupport (Markup)
>From my point of view the DataType element enumerations serve an
explicit purpose.
That purpose being to precisely codify what data values the Symbol
Parameter expects.
To better explain that . Let's take a step back and look at the
Symbolization schema :
1) ParameterDefinition element and its contained Parameters are a way of
presenting an interface to the Symbol.
2) The DataType element allows the Symbol consumer to look at the
interface and know what type of information is required. While one might
argue and say it should be a float, string etc. an equally compelling
argument is that DataType instead of hewing to such a generic approach
should be truly rich in its description by accurately specifying what
Data values it expect.(in that manner LineColor is different from
FillColor)
3) Additionally, its gives any intermediate software component the
ability to present the choices to the end user in a far more coherent
manner.
Traian, now to explicitly address the concerns (as per the thread
below).
You raise an interesting point when you say that the use of the
parameter inside the Angle element means that that the interface (aka
Parameter element) should not specify a DataType of type Angle as it is
redundant.
If you look at it from an DataModel POV, the end user should not concern
themselves beyond the interface i.e. They should not look beyond what is
defined within the ParameterDefinition element for a given Symbol. True,
the example is fairly simple but could easily have used LBL_ROTATION in
a complex expression within the Angle element. Should the user have to
parse the expression to figure out if LBL_ROTATION is used in the Angle
element ? I think not. The same applies to all the other elements within
the SymbolDefinition.
Cheers,
Vishal
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Traian
Stanev
Sent: Tuesday, September 18, 2007 9:44 AM
To: mapguide-internals at lists.osgeo.org
Subject: RE: [mapguide-internals] For Review : Mapguide RFC
31-SymbolDefinition Support for Edit Controls and RichTextSupport
(Markup)
I am concerned about the new additions to the DataType element. Most of
them are redunadant. Even in the example given in the RFC, the DataType
is set to Angle and specifies that the LBL_ROTATION parameter represents
an Angle. The LBL_ROTATION itself is already referenced inside an
<Angle> element, so there really is no point to specifying a data type
for it.
Apart from the redundancy, my concern is that client apps will be coded
to rely on those data type hints exclusively instead of inferring the
data types from the actual contents of the symbol and thus will be
unable to consume symbols created by third parties without undue burden
on the third party to add all those "optional" DataType elements.
Also, the element name DataType is not even meaningful anymore if it can
be set to things like "FillColor" or "LineColor" since arguably these
are both the same data type (color).
Traian
-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Vishal
Bangia
Sent: Tuesday, September 18, 2007 12:25 PM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] For Review : Mapguide RFC 31
-SymbolDefinition Support for Edit Controls and Rich TextSupport
(Markup)
Hi All,
Mapguide RFC 31 (SymbolDefinition Support for Edit Controls and Rich
Text Support (Markup)) is available for review.
http://trac.osgeo.org/mapguide/wiki/MapGuideRfc31
Your participation and feedback will be appreciated.
Thank you,
Vishal
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals
More information about the mapguide-internals
mailing list