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

Vishal Bangia vishal.bangia at autodesk.com
Wed Sep 19 23:56:15 EDT 2007


The whole take with the new SymbolDefinition Schema is that it introduces reuse of a Symbol. No more does a user have to define a symbol for every geometry type in every layer. A symbol that uses the SymbolDefinition schema is a resource which many different layers/users can use. In this scenario the clear distinction between the internals of a Symbol and its interface help a lot. 
Case to point , a customer might define a set of Symbols that meet a specific criteria. Every map published by that customer might use those very symbols . In other words, it’s a Library of Symbols. Is the user who creates the Map the creator of the symbols? Not necessarily (A city govt might pay a contractor to create symbols that meet a Govt. standard) . Does it empower the users of Mapguide Open Source to use fairly complex looking symbols easily ? YES!!! Does it encourage the creation of sophisticated symbols and in turn better looking maps?  YES!!

Similarly, the interface for all the symbols might follow a set specification, making use of different symbols easier for the end user.
 

Regarding possible errors in the SymbolDefinition due to DataType : flexibility, is a double edged sword. Nothing prevents the user from writing utter gibberish XML either or disregarding the SymbolDefinition schema ..

I do concede that it is a bit of extra complexity for the author of the symbol, but IMHO the whole SymbolDefinition schema is to facilitate the use(or may I say, reuse) of fairly sophisticated symbols that go way beyond the simple "orange square" example. This approach will pay enormous dividends for users who exercise that capability.


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: Wednesday, September 19, 2007 6:11 PM
To: MapGuide Internals Mail List; MapGuide Internals Mail List
Subject: RE: [mapguide-internals] For Review : Mapguide RFC31-SymbolDefinitionSupport for Edit Controls andRichTextSupport (Markup)

 
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
	




More information about the mapguide-internals mailing list