[mapguide-internals] For Review : MapguideRFC31-SymbolDefinitionSupport for Edit ControlsandRichTextSupport (Markup)

[Carsten Hess]

Traian,
 
if the data type is in an optionally supplied element (ParameterDefinition) why do you believe this RFC will make it required? If it does that will be a surprise to me and would be wrong. Again this whole section of the schema is meant to be metadata for those people who want to describe the parameters of their symbols (and the symbol itself).
 
Also, using the parameter name for such a thing as you describe hardly is a good solution without writing naming standards and enforcing them. So that can not be a solution as we would have to agree on the language of the standard and enforce it somehow which is hardly possible without a schema. 
 
Maybe this discussion is one about the value of metdata? After all ... I know a shp file is a road network when the shp file contains linear geometry and is called "Roads.shp", right? The industry though thought we need a better, descriptive and parsable way of describing this content as a road. Redundant? Yes ... needed? Yes ...
 
Cheers,
  Carsten

	-----OriginaTrail Message----- 
	From: mapguide-internals-bounces at lists.osgeo.org on behalf of Traian Stanev 
	Sent: Thu 9/20/2007 07:29 
	To: MapGuide Internals Mail List 
	Cc: 
	Subject: RE: [mapguide-internals] For Review : MapguideRFC31-SymbolDefinitionSupport for Edit ControlsandRichTextSupport (Markup)
	
	



	> -----Original Message----- 
	> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide- 
	> internals-bounces at lists.osgeo.org] On Behalf Of Carsten Hess 
	> Sent: Thursday, September 20, 2007 1:59 AM 
	> To: MapGuide Internals Mail List 
	> Subject: RE: [mapguide-internals] For Review : Mapguide RFC31- 
	> SymbolDefinitionSupport for Edit Controls andRichTextSupport (Markup) 
	> 
	> 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. 
	> 

	Yes, the symbol will display correctly. I would like it to also "work" for other things like setting parameters without having to add the DataType elements. It seems to me like this RFC will make the DataType de facto required to do such setting of parameters.

	
	> 
	> 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. 
	> 

	I agree that the display name can be useful, as I mention below. 
	  
	> 
	> 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... 
	> 

	In this case one can name the parameter's display name HATCH_COLOR and in the description it could say something like "The color of the hatch pattern". It can be done with the current schema without DataType gymnastics.

	
	> 
	> 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. 
	> 

	Yes, that's why I claim there shouldn’t be any! The more elements we add to the schema, the harder it is to make a symbol. Even if those elements are optional. Especially when it is not clear what new information they add.

	
	> 
	> 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. 
	> 

	I understand what it is. I am not convinced it is necessary or desirable. Unlike metadata, you can potentially break the symbol definition by specifying the wrong DataType. Also, it is not clear what happens when the same parameter is used inside two different elements of the symbol definition -- for example setting font height and line width inside the symbol definition to be equal to the same parameter. What is the DataType then?



	Traian