[mapguide-internals] PSC: Motion RE: Proposed minor changes to RFC 14

Tom Fukushima tom.fukushima at autodesk.com
Mon Mar 19 12:48:24 EDT 2007

Thanks Walt, these look good.

Hi PSC members,

I motion that we accept these changes to RFC 14.

+1 Tom


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Walt
Sent: Thursday, March 15, 2007 9:15 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Proposed minor changes to RFC 14

Now that implementation has started on RFC 14, we've come up with a list
of (mostly-minor) symbolization schema changes that need to be made.
Please have a quick look and reply if you have questions or issues.

*	remove invalid enumerations from
SymbolInstance::CheckExclusionRegion element
		=> it should be a plain xs:string

*	change SymbolInstance::SizeContext to be a SizeContextType
		=> this is for consistency

*	make LineUsage::VertexAngleLimit an xs:string type
		=> the type is missing in the schema

*	change all enumerated type properties to plain strings so they
support expressions
		=> PointUsage::AngleControl
		=> LineUsage::AngleControl
		=> LineUsage::UnitsControl
		=> LineUsage::VertexControl
		=> AreaUsage::OriginalControl
		=> AreaUsage::AngleControl
		=> AreaUsage::ClippingControl
		=> Path::LineCap
		=> Path::LineJoin
		=> GraphicBaseType::ResizeControl
		=> ResizeBox::GrowControl

*	add a VertexJoin property on LineUsage
		=> all graphic elements in the simple symbol use this
value to determine their wrapping behavior at vertices

*	rename Parameter::ValueList to AllowedValues

*	rename SimpleSymbol::SimpleSymbolReference to SymbolReference
		=> it's already clear enough that this is a
SimpleSymbolReference because this is part of SimpleSymbol

*	switch order of elements in AreaUsage
		=> switch AngleControl and OriginControl
		=> put Angle before OriginX and OriginY
		=> makes AreaUsage more consistent with LineUsage and

*	change Graphics collection to allow 0 to unbounded elements
		=> currently it requires at least one element
		=> users want to save their symbols while editing them
		=> they may temporarily not contain any graphic elements

*	same change for the CompoundSymbolDefinition::SimpleSymbol
		=> allow 0 to unbounded symbols

*	same change for the CompositeSymbolization::SymbolInstance
		=> allow 0 to unbounded symbol instances

*	rework SymbolDefinition element
		=> create separate SimpleSymbolDefinition and
CompoundSymbolDefinition elements which are of the corresponding types
		=> update SymbolInstance to have either a
SymbolReference, SimpleSymbolDefinition, or CompoundSymbolDefinition
		=> delete SymbolDefinition and SymbolDefinitionType

*	document the default value for all optional elements

*	for properties supporting expressions that must evaluate to
certain string values, document what those values are


 W       E         @__   __o
   A   T   R   @___    _ \<,_
     L           @_   (*)/ (*)

mapguide-internals mailing list
mapguide-internals at lists.osgeo.org

More information about the mapguide-internals mailing list