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

[Traian Stanev]

Is it possible to un-ambiguously infer where a parameter is used (which determines its data type)? I think the answer to this is yes. If the answer is yes, then the things you mention are possible without adding explicit DataType hint to the schema. I grant you, that it is probably more development work for an application that consumes symbol definitions, but it is not more work for the user or author of a symbol definition. The user does not have the parse an expression to find out that LBL_ROTATION is used inside the <Angle> tag, since the user was probably the one who set the angle to be equal to LBL_ROTATION anyway.
 
Another way to look at it -- the DataType element adds the ability to create an inconsistent symbol definition by using a parameter in say, <FillColor> and then setting its <DataType> to Angle. What happens when I set FillColor to 15 degrees?
 
 
Traian
 
 

	-----Original Message----- 
	From: mapguide-internals-bounces at lists.osgeo.org on behalf of Vishal Bangia 
	Sent: Wed 9/19/2007 7:57 PM 
	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