20,741
edits
PropertyList XML files: Difference between revisions
Jump to navigation
Jump to search
m
property attributes and yasim differences: http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04170.html
m (David Megginson: http://www.mail-archive.com/flightgear-devel@flightgear.org/msg03740.html) |
m (property attributes and yasim differences: http://www.mail-archive.com/flightgear-devel@flightgear.org/msg04170.html) |
||
| Line 6: | Line 6: | ||
Most configuration files in FlightGear are XML-encoded property lists. PropertyList-encoded XML files use a subset of XML to map the property tree to XML space and vice versa. PropertyList-XML files are the main mechanism to populate the FlightGear property tree (or a sub branch of it) from XML files, but also to serialize (save) property tree/branch state to an XML file. XML attributes are mainly used as meta-directives for the property tree. | Most configuration files in FlightGear are XML-encoded property lists. PropertyList-encoded XML files use a subset of XML to map the property tree to XML space and vice versa. PropertyList-XML files are the main mechanism to populate the FlightGear property tree (or a sub branch of it) from XML files, but also to serialize (save) property tree/branch state to an XML file. XML attributes are mainly used as meta-directives for the property tree. | ||
Right now, we use attributes for meta-information (data type, read/write flags, aliasing, and tracing). As long as we use attributes for meta-information and elements for data, we'll have a clean upgrade path; otherwise, we'll end up with lots of reserved names (you cannot have a property named "alias", for example, because it might conflict with the attribute), and versioning problems (there's a new attribute named "foo", so any existing "foo" properties have to be renamed). | |||
The current practice is a little verbose compared with a custom-designed, single-purpose XML format, but it generalizes nicely. Another alternative would be to use XML Namespaces, but (while I support them) those have their detractors even in the hard-core XML community, and I'm worried that they'll confuse people a bit in FlightGear. | |||
A custom-designed XML format for panels, sound, animations, FDMs, etc. could be *much* less verbose, but then we'd be managing n different XML-based formats and parsing libraries. | |||
Not everything that is read from an XML file resides in the main property tree; some subsystems also use XML files for initial configuration information. There are different kinds of data. The property tree is meant to represent the shared state of the program; when a subsystem happens to use an XML file to set up its internal state -- information that is of no use to the rest of the program and that cannot be changed without a reinit. Temporary trees are usually deleted as soon as the subsystem is set up (i.e. they exist for perhaps 0.1 sec). We could just as easily use another format for internal initialization, but since the XML support is already available, it was the easiest route. | Not everything that is read from an XML file resides in the main property tree; some subsystems also use XML files for initial configuration information. There are different kinds of data. The property tree is meant to represent the shared state of the program; when a subsystem happens to use an XML file to set up its internal state -- information that is of no use to the rest of the program and that cannot be changed without a reinit. Temporary trees are usually deleted as soon as the subsystem is set up (i.e. they exist for perhaps 0.1 sec). We could just as easily use another format for internal initialization, but since the XML support is already available, it was the easiest route. | ||
| Line 38: | Line 44: | ||
YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear. For YASim, see $FG_ROOT/Aircraft-yasim/README.yasim in the base package; for JSBSim, see the documentation at http://jsbsim.sourceforge.net/. UIUC uses a non-XML config-file format. | YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear. For YASim, see $FG_ROOT/Aircraft-yasim/README.yasim in the base package; for JSBSim, see the documentation at http://jsbsim.sourceforge.net/. UIUC uses a non-XML config-file format. | ||
The one advantage of Yasim's approach is efficiency -- Andy copies from the XML straight into the YASim data structures, without building up and tearing down an in-memory property tree first. For large-scale XML implementations, we *have* to do things that way -- the DOM and XSLT tend to break down catastrophically for large XML documents or high volume. That's why we designed the Simple API for XML (SAX). | |||
Efficiency doesn't matter much for YASim, since we're a short file, and we're reading it only once. If we're ever processing a lot of XML in the main loop, say, over a network connection or from large GIS databases, we'll need to go with a streaming approach like Andy used. | |||
To work with PropertyList-XML files, you can use various means, such as: | To work with PropertyList-XML files, you can use various means, such as: | ||