XML - why?

[Paul]

DISCLAIMER: I have nothing against XML. In fact, I plan to use XML to format certain data for my own projects.

What I want to know is this: what are the benefits gained by having Celestia move to using XML for (most or all of) its data?
One advantage I guess could be standardisation, so that people writing programs that output data intended for Celestia can write code that outputs XML with the intended properties. With a small amount of effort they can do this already, although XML can make it more backwards-compatible.

Is that it? Am I missing something really useful about XML? I look forward to being enlightened.

[dtessman]

The bad:
One has to parse XML (as opposed to a flat file format).
It is inheirantly verbose.
If one is not careful, the syntax can become confusing.
Defining and indexing it is royal pain.

The good:
It is a standard.
It uses plain text.
Via XML Schema datatypes can be well defined.
It is extendable without breaking legacy implementations.

---

For small "load-once" data structures is works just fine (ex: .scc files)
When choosing it for this type of stuff, it provides a familiar starting point ("oh gee look its XML") as well as a finite and well known way of defining what values are allowed (XML Schema). The programmer can leverage other's coding by using off-the-shelf parsers, and other tools. Because it is extensible, the implementation is flexible. The programmer can add features without breaking their user's existing configuration files (though this is certainly possible with other free-form text formats as well, such as .scc).

For large repetitive data structures it stinks (ex: stars.dat).
In this case the only use would be as a standardized import/export format.

Use of XML allows one to leverage the coding of others. Be it external to the application, such as you mentioned, or internal to the app through the use of parsing libraries, etc.
----
Where XML really comes into play is when you have a heterogeneous mix of applications all sharing data. It allows one to build a single point of integration, rather than a network of integration points.

So If I have two applications that share data, such as say StarGen (planetary system generator) and Celestia. Hey, no problem I can use any format as long as Celestia and StarGen agree. If however, I have say StarGen and another planetary system generator (call it StarMaker). Then Celestia has to either dictate a single import format that both StarGen and StarMaker have to conform too, or Celestia would have to implement two import parsers. Now do a many to many, by saying that StarGen and StarMaker also want to export their data to some other applications (lets call it AstroGlobe). Now we have four potential formats to support and translate between. The problem just grows as more sources or sinks of data become available.

XML itself removes at least one problem, by creating a standard syntax. ASCII removed the character encoding problem a long time ago. (IBM mainframes and AS/400s not withstanding). Transaction standards organizations (such as SpaceGear.Org) is attempting to remove the lexicographic and semantic problem.

Hope that helps,