[mapguide-internals] Motion to vote on RFC 31
SymbolDefinitionSupport for Edit Controls and Rich Text Support
(Markup)
Paul Spencer
pspencer at dmsolutions.ca
Mon Oct 1 20:51:42 EDT 2007
Thomas,
absolutely fabulous! Thanks
Paul
On 1-Oct-07, at 7:12 PM, Thomas M. Tuerke wrote:
> 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
> _______________________________________________
> 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/ |
+-----------------------------------------------------------------+
More information about the mapguide-internals
mailing list