PropertyList XML files: Difference between revisions

Jump to navigation Jump to search

PropertyList XML files (view source)

Revision as of 03:29, 20 May 2013

803 bytes added ,  20 May 2013
m
Cleanup
mNo edit summary
m (Cleanup)
Line 7: Line 7:
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.


One advantage of the XML representation is its conceptual simplicity. Every element except for the root PropertyList container represents exactly one property, and every attribute represents metadata for the property associated with its element.
One advantage of the XML representation is its conceptual simplicity. Every element except for the root PropertyList container represents exactly one property, and every attribute represents metadata for the property associated with its element.
 
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 and are read into a temporary tree and subsequently discarded. The main property tree is meant to represent the shared state of the program, but when a subsystem happens to use an XML file to set up its internal state that information is often of no use to the rest of the program and thus does not need to continually be in the main tree. 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.
 
The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, since it allows some common structure and reusable code among all the formats.  Imagine if we had one file format for preferences, a different one for panels (say, with fixed-length fields), a different one for saving a flight (perhaps a binary format), another one for sound configuration (perhaps an INI file), a different one for top-level aircraft configuration (perhaps CSV), yet another one for configuring 3D models (perhaps embedded data strings in the 3D files themselves), etc. etc.
 
We have config files for totally different purposes, and the fact that they all use XML is simply a convenience for programmers and customizers.
Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT):
 
* preferences.xml    - the top-level default preferences
* joysticks.xml      - default joystick bindings, included by preferences.xml
* keyboard.xml      - default keyboard bindings, included by preferences.xml
* Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml)
 
Basically, these are the main files in the base package that affect FlightGear's main property tree.  Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format:
 
* materials.xml      - define the materials (textures, colour, lighting) for use in the scenery
* HUDS/**/*.xml      - configuration files to define the various heads-up displays
* Aircraft/*/*-sound.xml - configuration files to define sounds played for various aircraft
* Aircraft/*/Panels/*-panel.xml - configuration files to define 2D panels for various aircraft.
* Aircraft/*/Instruments/*.xml - configuration files for individual instruments included by the 2D panels.
* Aircraft/Instruments/*.xml - ditto
* Aircraft/*/Models/*.xml - animation files for a .ac file, oodles of <animation> nodes!
 
We also use some XML-based formats that do not (yet?) follow the property-list conventions, including the following:
 
*  Aircraft/*/*.xml    - JSBSim aero model config files
*  Aircraft/Aircraft-yasim/*.xml - YASim aero model config files
*  Engine/*.xml        - JSBSim engine and thruster config files
 
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 it's 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:
Line 47: Line 13:
* Nasal (props.nas, io.nas)
* Nasal (props.nas, io.nas)
* C++ APIs (see links at the end of the navigation sidebar)
* C++ APIs (see links at the end of the navigation sidebar)
* Text editor: manually edit XML files


There are several places to look for properties; one is in the aircraft files, another is all Nasal files, and the last place (and often most useful!) is grepping (searching) through the C++ code. To determine how a property works and what it does often requires looking through any code that uses it. This is a part of FlightGear that we could certainly document better.
== The PropertyList format ==


As for the relationship between XML and the Property Tree, in some cases in FG (most notably preferences.xml and each AIRCRAFT-set.xml file), the <PropertyList> format directly defines properties in FlightGear's global property tree. In other cases, like the animation files given by /sim/model/path, those do not define properties but the <PropertyList> format is used as a matter of convenience so that FG can parse all of its XML files using the same mechanism and to keep the fundamental structure the same. XML has a lot of different dialects, and having only one for FlightGear really makes it easier, especially since it is very intuitive
The root element of each file is always named <PropertyList>. Tags are almost always found in pairs, with the closing tag having a slash prefixing the tag name, i.e </PropertyList>, just like in any other XML dialect. The exception is the tag representing an aliased property. In this case a slash is prepended to the closing angle bracket:
 
<syntaxhighlight lang="xml">
The root element of each file is always named <PropertyList>. Tags are almost always found in pairs, with the closing tag having a slash prefixing the tag name, i.e </PropertyList>. The exception is the tag representing an aliased property. In this case a slash is prepended to the closing angle bracket.
<prop alias="/sim/foo"/>
</syntaxhighlight>


A minimal example of a complete property list encoded XML file, looks like this:
A minimal example of a complete property list encoded XML file, looks like this:
Line 63: Line 31:
</syntaxhighlight>
</syntaxhighlight>


Property typing is optional, all properties are by default string/unspecified and are transparently converted by the property tree:
Property typing is optional, all properties are by default string/unspecified and are transparently converted by the property tree, but it never hurts, especially when including spaces around numbees:


<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
Line 69: Line 37:
  <PropertyList>
  <PropertyList>
   <foo type="string">Hello</foo>
   <foo type="string">Hello</foo>
   <pi type="float">3.14</pi>
   <pi type="float"> 3.14 </pi>
   <boo type="bool">true</boo>
   <boo type="bool">true</boo>
  </PropertyList>
  </PropertyList>
Line 120: Line 88:




We can also create new *-set.xml files by subtyping existing ones.  For example, if someone made a DC-3 model for JSBSim, we could subclass the YASim config file like this:
We can also create new *-set.xml files by subtyping existing ones.  For example, if someone made a DC-3 model for JSBSim, we could subclass from the YASim config file like this:


<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
Line 131: Line 99:
   </PropertyList>
   </PropertyList>
</syntaxhighlight>
</syntaxhighlight>
Emmanuel Baranger's models tend to use this technique lot and often have several XML files: the first (the -set.xml) contains very basic information, often just author and version number, and includes the next; the second is for FDM-specific properties (the -yasim-cnf or -jsbsim-cnf); and the last has FDM-independent things like flap settings (the -base.xml). This structuring allows for maximum reusability between FDMs and makes it easier for someone to come along and add another FDM to a model.


For further information please refer to [[$FG_ROOT]]/Docs/README.introduction and [[$FG_ROOT]]/Docs/README.properties.
For further information please refer to [[$FG_ROOT]]/Docs/README.introduction and [[$FG_ROOT]]/Docs/README.properties.
== PropertyList-based configuration files ==
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 and are read into a temporary tree and subsequently discarded. The main property tree is meant to represent the shared state of the program, but when a subsystem happens to use an XML file to set up its internal state that information is ofteb of no use to the rest of the program and thus does not need to continually be in the main tree. 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.
The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, since it allows some common structure and reusable code among all the formats.  Imagine if we had one file format for preferences, a different one for panels (say, with fixed-length fields), a different one for saving a flight (perhaps a binary format), another one for sound configuration (perhaps an INI file), a different one for top-level aircraft configuration (perhaps CSV), yet another one for configuring 3D models (perhaps embedded data strings in the 3D files themselves), etc. etc.
We have config files for totally different purposes, and the fact that they all use XML is simply a convenience for programmers and customizers.
Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT):
* preferences.xml    - the top-level default preferences
* joysticks.xml      - default joystick bindings, included by preferences.xml
* keyboard.xml      - default keyboard bindings, included by preferences.xml
* Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml)
Basically, these are the main files in the base package that affect FlightGear's main property tree.  Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format:
* materials.xml      - define the materials (textures, colour, lighting) for use in the scenery
* HUDS/**/*.xml      - configuration files to define the various heads-up displays
* Aircraft/*/*-sound.xml - configuration files to define sounds played for various aircraft
* Aircraft/*/Panels/*-panel.xml - configuration files to define 2D panels for various aircraft.
* Aircraft/*/Instruments/*.xml - configuration files for individual instruments included by the 2D panels.
* Aircraft/Instruments/*.xml - ditto
* Aircraft/*/Models/*.xml - animation files for a .ac file, oodles of <animation> nodes!
We also use some XML-based formats that do not (yet?) follow the property-list conventions, including the following:
*  Aircraft/*/*.xml    - JSBSim aero model config files
*  Aircraft/Aircraft-yasim/*.xml - YASim aero model config files
*  Engine/*.xml        - JSBSim engine and thruster config files
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 it's 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.
There are several places to look for properties; one is in the aircraft files, another is all Nasal files, and the last place (and often most useful!) is grepping (searching) through the C++ code. To determine how a property works and what it does often requires looking through any code that uses it. This is a part of FlightGear that we could certainly document better.
As for the relationship between XML and the Property Tree, in some cases in FG (most notably preferences.xml and each AIRCRAFT-set.xml file), the <PropertyList> format directly defines properties in FlightGear's global property tree. In other cases, like the animation files given by /sim/model/path, those do not define properties but the <PropertyList> format is used as a matter of convenience so that FG can parse all of its XML files using the same mechanism and to keep the fundamental structure the same. XML has a lot of different dialects, and having only one for FlightGear really makes it easier, especially since it is very intuitive


== Pros for the current implementation ==
== Pros for the current implementation ==
Philosopher
395

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/60305"

Navigation menu