[mapguide-internals]ForReview:MapguideRFC31-SymbolDefinitionSupportforEditControlsandRichTextSupport(Markup)

[Carsten Hess]

Right, I guess this is where the core of the discussion is now. Is it
required to use the style definitions effectively? This is also
non-measurable thanks to words like effective and "eschewing" (thanks
for letting me use a big word too :)). So it becomes hard to argue for
or against each side "effectively" :)

To me: If any tools rely on optional fields - that would be bad news and
not the intention of this RFC the way I understand. I would consider
that a bug.

Are there apps that may present symbols to the user for re-using them,
and are able to do a better presentation in the UI if these fields are
available? To me that is the question we should ask. 

Now of course I can't hold back. Once we ask the later question: I would
like you to find two people that agree on an "effective" or better UI
(unless it is from apple of course - then there is no question out of
principal :))

Cheers,
  Carsten

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason
Birch
Sent: Tuesday, September 25, 2007 2:29 AM
To: MapGuide Internals Mail List
Subject: RE:
[mapguide-internals]ForReview:MapguideRFC31-SymbolDefinitionSupportforEd
itControlsandRichTextSupport(Markup)

Oh sure, wait until I'm at foss4g to reply :)
 
If these metadata are required in order to use the style definitions
effectively in the various map authoring tools, then they're not really
optional.  But I guess that if there's a style creation tool in the same
author, then it doesn't really matter...
 
The definition of a MapGuide user is indeed hard.  My thought is for
MapGuide to keep its current levels of usability for simple Studio users
(little or no application customisation) while making it even easier for
application developers to write incredible interactive applications.  I
don't think that there is any way of doing this without eschewing
complexity where possible.
 
Yay, I got in a big word :)
 
Regardless, I'm out of my depth on the XML, and am happy with whatever
shakes out.
 
Jason
 
________________________________

From: Carsten Hess
Subject: RE: [mapguide-internals]
ForReview:MapguideRFC31-SymbolDefinitionSupportforEditControlsandRichTex
tSupport (Markup)

Jason,

Yes, I think the use case is the symbol library and a way to describe
the content of the symbol library. Theoretically we wouldn't have needed
the parameters that are part of the symbols at all as we could have
created a new symbol for each use. That would have been faster and
easier for MapGuide but makes the symbols less reusable.

Creating good symbols like the FGDC library is quite a bit of work and
not trivial - in no GIS package I know off - and I am still hoping that
we will all contribute ultimately to create one big library that can be
part of MapGUide. I think that would make it easier to use...

In the end I think this metadata will make symbols easier to use ...
creating symbols a bit more complex. Personally I always push to make
using things easier after all that is what software is all about - make
the users life easier.
With a platform like mapguide the question though is: who is not a user?
In this case we optimize for the person who is creating and viewing a
Map by reusing symbols not the person who creates the symbols.

Said all that ... I want to make sure that everyone is aware that these
sections in the XML are optional for symbols. They will work fine
without it :)

Cheers,
  Carsten