[mapguide-internals] Motion to vote on RFC 31 SymbolDefinitionSupport for Edit Controls and Rich Text Support (Markup)

[Thomas M. Tuerke]

Paul Spencer wrote:
> I think there was sufficient discussion on this to warrant a summary  
> of the opinions and the conclusion as to why the RFC was changed or  
> not based on feedback.  

In that light:

The sponsors of RFC31 have examined the offered feedback, and with
considerable thought and deliberation, decided to leave the RFC as it
stands, offering this justification in doing so.

The feedback offered falls roughly into these categories:

1.	Undue Burden: The point has been raised that the addition of the
<DataType> element may be an "undue burden" on an authoring tool.
2.	Redundant: The claim has been made that the information is
redundant, and can be gleaned algorithmically by the client.
3.	Misrepresentation: A further point was made an incorrect
designation might misrepresent the actual use.
4.	Alternate Typing Proposal: a counter-proposal outlined a
rigorous grammar for specifying valid values.

The sponsors provide this rebuttal:

1.	Undue burden: The authoring software might require additional
effort, but whether this rises to the level of an undue burden is
debatable; the claim does seem a bit hyperbolic.

2.	Redundant: It's true that DataType summarizes what can sometimes
be gotten by scanning the entire symbol definition.  Still, this poses
two problems:

  a.	The DataType element may be a burden on the authoring software.
The absence of the element may be a greater burden on the client
software; the scan is a non-trivial algorithmic undertaking.

  b.	Such an algorithm would be heuristic and possibly fallible. It
would essentially be trying to second-guess the author's intent based on
an examination of contextual uses.

The DataType element represents a declaration of intent on the part of
the symbol's author.  It is also at-hand; no need to search for it.
Finally, it offers semantic value that isn't present in a strictly
storage-type declaration.

3.	Misrepresentation: It's true that the DataType element can be
inconsistent with actual usage.  But this is just part of a bigger
problem - badly-written symbols - and robust client software needs to
cope with these case regardless.  In the case of DataType, the effect is
an unusual UI, the same as when the heuristic analysis incorrectly
deduced the intended use.

4.	Alternate Typing Proposal: The alternate type declaration
alluded to later in the thread presents some interesting ideas (quite
similar to ones raised in discussion during the design process, as it
happens.)  However, the thought is that the counter-proposal, while
quite powerful, is more complex than what is needed at the moment.
Also, while defining a stronger physical storage description of values,
it lacks in the area of semantic declaration. Citing the example: it's
one thing to know that three strings of values between 00 through ff are
needed, it's another thing entirely to know that these come together to
create a color.


Highlight of discussions surrounding RFC 31:

Traian expressed his apprehensions about the DataType element (or, more
precisely, the addition of new enumerated values in this RFC -- the
actual element predates this RFC.)  He suggests that heuristics can be
used to infer what the DataType elements explicitly declare.  He asserts
that the addition of the DataType element is an "undue burden" on symbol
creators.

Vishal replied that semantic type information, not only basic type
information, is incorporated into the declaration.  This facilitates a
rapid evaluation of the symbol parameter definition by the client
(without having to crawl around the symbol definition to make
inferential leaps.)  He points out that in certain contexts, a generic
type, (or even a more specific but still general type) may not suitably
capture possibly nuanced difference between (for example) Line and Fill
color.

Traian asserts that the DataType is redundant in light of the ability to
"un-ambiguously infer where a parameter is used" but concedes "that it
is probably more development work for an application that consumes
symbol definitions"  The assertion remains that it is more work for the
author of the symbol definition.  He airs an apprehension that it's
possible for the symbol author to misrepresent information with a
DataType declaration contradicting actual usage.

Carsten likens the proposal to classic metadata; "not really needed, but
useful when looking at the actual data."

In another thread, Jason (Nogar) agreed "there would be added value in
an (entirely optional) class of additional metadata" such as is being
proposed, but repeats the assertion that there's little benefit for
library creators.  He also suggests that heuristic parsing of the symbol
(complicated, as mentioned previously) would yield adequate results.
[He offers a counter-proposal with a stronger actual typing system which
would allow rigorous validation of values being input, but omitting any
semantic value which would assist the UI in substituting stock widgets
with user-friendly controls.]

Carsten replied, summarizing material already discussed.
 
Recap:
*	DataType simplifies parsing for the client, while adding some
effort on the part of the author.
*	The information provided is alternately considered either
redundant, or readily-available metadata.
*	A proposed alternative to the author-provided DataType
declaration is for the client to scan the symbol definition,
heuristically inferring its usage by context.  No specific algorithm has
been suggested.
*	The DataType element is described as optional.  There may be
practical implications with certain UIs behaving sub-optimally in its
absence, however.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Paul
Spencer (External)
Sent: Wednesday, September 26, 2007 10:38 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Motion to vote on RFC 31
SymbolDefinitionSupport for Edit Controls and Rich Text Support (Markup)

Tom,

I think there was sufficient discussion on this to warrant a summary  
of the opinions and the conclusion as to why the RFC was changed or  
not based on feedback.  I am fairly sure we didn't reach a consensus  
on whether this change is a good idea from the folks involved in the  
discussion.  I am not opposed to moving ahead with it but I do think  
we should have a summary before we vote.

Cheers

Paul

On 26-Sep-07, at 1:47 PM, Tom Fukushima wrote:

> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc31
>
> It looks like the dust has settled on this RFC now. I motion that we
> vote on RFC 31 SymbolDefinition Support for Edit Controls and Rich  
> Text
> Support (Markup).
>
> +1 Tom
>
> Thanks
> Tom
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals

+-----------------------------------------------------------------+
|Paul Spencer                          pspencer at dmsolutions.ca    |
+-----------------------------------------------------------------+
|Chief Technology Officer                                         |
|DM Solutions Group Inc                http://www.dmsolutions.ca/ |
+-----------------------------------------------------------------+





_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals