I was wondering how this works.
Do you load the complete map when the game starts up, or do you load parts of the map at runtime?
And how would you save the maps? Would it be in XML or some binary format?
I agree with eBusiness. It depends on the size and how you want to edit it.
Estimate the byte size of your map in a reasonably compact representation. Also decide which parts of the map can change as the game plays. Those parts that don't change can be loaded and don't have to be saved. If the estimated size is small, just store everything in memory. It's not worth the extra complexity of loading parts of the map and tracking what you've loaded or not, unless the data is so large that it's necessary.
For example if you were writing Civilization II, your map size might be 100x100 tiles.
That's under 30k for a compact binary representation the Civ II map + objects, so you can store all of it in memory, even if you use a verbose format that's much larger. I got the above numbers from someone reverse engineering the Civ II map structure.
Daggerfall, considered by some to have a ridiculously large map, appears to be 5000x2500 and around 25 megabytes, but it also has a large number of NPCs (750,000 is what I've read but that seems very high). On today's desktop/laptop machines this too could fit into memory, but on mobile devices or browsers that might be a bit too big. There's a wiki describing the Daggerfall map format.
You can reduce the size by identifying and factoring out redundancy. For example, instead of storing 100,000 identical trees or swords each in an XML format, store one tree and one sword and 100,000 references to them. In the binary formats that reference might be only 1 or 2 bytes, and in a more verbose format the reference can still be reasonably small.
Do the simplest thing that works for your game. If the map is small, it doesn't matter if you use a compact or verbose format. If the compact format would fit into memory but the verbose format would not, you have to decide whether the extra work of the binary format is more or less than the extra work of loading portions of the map. That'll depend on the game. In a Civ-like game where you need all the data to simulate turns, the binary format is probably a better choice. In a Daggerfall-like game where you don't need to load areas except what's near the player, loading portions of the map is probably a better choice. If the map is so big that even the compact format won't fit in memory, then first ask yourself if it's really worth all the extra work to deal with it, and if so, design a binary format that you can load portions of.
For my current (hobby) project, the maps and all the objects on them fit into 50 MB, so keeping it all in memory would be fine. However, I want it to run in the browser, and 50 MB is more than I want to transfer over the network, so I'm keeping them all in memory on the server and then loading only parts of the world in the client. My map tiles are 1 byte per tile, 2048x2048 tiles (4 MB). The objects (trees, chairs, orcs, etc.) are JSON-encoded for simplicity. In the client I only load the map areas (including their objects) that are near the player.
There is no one answer to these questions. These are all inherently up to you.
You could save maps anyway you like and display/render them at any time.
How much to load depends at least on how big the map is, if the data can reasonably fit in memory then there is really no reason to bother with progressive loading.
The most notable thing XML does is take up a lot of extra storage/memory/network space/traffic. If you think using XML is fun, be sure to do so only for relatively small amounts of data.
When you design a data format you should have in mind how you want to edit this data. You could use a simple text editor to write your data as a plain text file, you could use these files directly or you could convert them to a binary format to save space. You could use an image editor to make your levels as bitmaps, again, you might want to convert to a smaller file.
Or you could make your own editor, in which case there is little reason for not using a compact binary format.