[mapguide-internals] For Review : Mapguide RFC31-SymbolDefinition Support for Edit Controls andRichTextSupport (Markup)

[Carsten Hess]

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