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

[Traian Stanev]

What happens in this case?

> 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


> -----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 10:40 AM
> To: MapGuide Internals Mail List; MapGuide Internals Mail List
> Subject: RE: [mapguide-internals] For Review :MapguideRFC31-
> SymbolDefinitionSupport for EditControlsandRichTextSupport (Markup)
> 
> 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
> 
> 
> 
>