Call for comments: modifying format of *.map.xml

Developer
Jan 6, 2011 at 9:18 PM
Edited Jan 6, 2011 at 11:08 PM

We're considering modifying the way settings are stored so that plugins can include settings information.

I'd like to hear comments on whether providing an upgrade tool (which could migrate existing .map.xml files to the new format) would be sufficient, or if there are compelling reasons to provide backwards compatibility.

Also, we might want to consider how settings would be stored if DotSpatial were used on a webserver.

 

I just learned that the .map.xml file format was created for DotSpatial and is not used in MapWindow 4. Is there a tool that converts .mwprj to .map.xml? Is there any reason we wouldn't want to use "dspx" as the extension? I think this would be simpler than the double dot extension. Is it safe to completely rewrite the file format at this point?

Developer
Jan 6, 2011 at 11:22 PM

If the file ends in .xml I think it is more digestible to other xml readers.  This was Darryl's contribution, and it did seem a little strange, but at the same time, the world could use one less file extension.  Having the double extension gives clarity for what it is for but still direct access to xml.  We don't have any MapWindow 4 compatibility between the two, they rely on totally different principals.  The DotSpatial XML content is generated with some code that also carefully identifies not just the properties to be serialized, but also reports the class type that was serialized.  This is critical when reconstructing content from an interface.  You don't necessarilly know what classes were stored as ISymbol just from the definition of a PointSymbolizer.  So those have to be reported.  This sort of behavior was never available in MW4, which was strictly about serializing the descriptive content and contained no information about the object architecture.

Adding new content to the Map.XML will not cause issues.  XML files are designed so that if you are reading them correctly, new content is ignored by older code, and newer parameters are considered optional in the newer code.  This means the files will remain compatible within DotSpatial so long as you don't meddle to much with the underlying serialization object logic that defines how the class types are serialized and re-serialized.  I updated that code recently to ignore the version of the classes so that the auto-incrementing version number doesn't break things.  Adding new things to the file will be no problem though.

Also, for certain application settings, you might not want to store that in the map.  I'm just thinking about it, and I think Microsoft has a project settings system already in place that is pretty easy to use.  So for things like remembering whether plug-ins are turned on or off, I think that should be stored as a Project Setting and not stored in a specific map.  Providing access to the DotSpatial project settings tool on the plugin args might be a smarter way for plug-ins to be able to store system settings for the application that have nothing to do with a specific map that is being saved or loaded.  But yes, it would also be good to allow the plug-ins to have access to the map xml as well.

Just some thoughts.

Coordinator
Jan 7, 2011 at 12:12 AM

At this stage we have a small enough user group that a well documented process, rather than a tool, should be satisfactory.

--------
Sent from my Droid

On Jan 7, 2011 5:18 AM, "mudnug" <notifications@codeplex.com> wrote:
> From: mudnug
>
> We're considering modifying the way settings are stored so that plugins can include settings information.I'd like to hear comments on whether providing an upgrade tool (which could migrate existing .map.xml files to the new format) would be sufficient, or if there are compelling reasons to provide backwards compatibility.Also, we might want to consider how settings would be stored if DotSpatial were used on a webserver.
>
>
Developer
Jan 7, 2011 at 6:11 PM
shade1974 wrote:

Having the double extension gives clarity for what it is for but still direct access to xml.  

 

Are there a lot of people that are opening and editing these settings without using MapWindow/DotSpatial E.g., in notepad?

 

Developer
Jan 7, 2011 at 6:21 PM

Notepad is a bad example since it would work exactly the same regardless of the file extension.  However people have text editors that recognize the xml extension and provide syntactical help and color coding to help spot problems.  Visual studio, for instance, has a built in xml editor.  If you name it a custom extension type, then these tools will not recognize that the xml formatting should be used.  As to how frequently someone will do this I can't say.  If we wanted to prevent this sort of thing we would just save it as a binary file.  The reason to use xml is to make it human readable.

Ted

 

Developer
Jan 7, 2011 at 6:51 PM
Edited Jan 7, 2011 at 6:54 PM

Okay. I don't know of any editors that have that issue besides Visual Studio.

There are lots of examples of file types that are internally xml, but don't advertise it as part of their extension. Take for example .snippet files that Visual Studio uses.
Double extension files certainly got a bad rap when they were heavily used to propagate viruses a while back.
Developer
Jan 7, 2011 at 6:57 PM

Hmm.  Was not aware of the virus thing, but I have a stupidly restrictive set of "security settings" on my work computer and haven't had any troubles from the map.xml pattern.  If it causes an actual problem for someone, I could see changing it, but for now, it seems better to stay consistent.

Ted