2,561
edits
m (→Scope) |
m (→Implementation) |
||
| Line 94: | Line 94: | ||
Because of this, but also because hardcoding such tag names (i.e. property paths) would be unnecessarily tedious, given that FlightGear itself does not yet actively use this sort of information at the moment to provide aircraft picker/sorting facilities, one could simply by convention have ALL tags below one specific node (i.e. PropertyList/sim/aircraft-status/) -regardless- of their name be honored by potential search frontends. | Because of this, but also because hardcoding such tag names (i.e. property paths) would be unnecessarily tedious, given that FlightGear itself does not yet actively use this sort of information at the moment to provide aircraft picker/sorting facilities, one could simply by convention have ALL tags below one specific node (i.e. PropertyList/sim/aircraft-status/) -regardless- of their name be honored by potential search frontends. | ||
===Future Extendability === | |||
Because of the easy and flexibility of directly using XML/PropertyList files together with the FlightGear Property Tree, this approach to supporting more finely-grained status information tracking is extremely powerful and is promising enough to even support highly detailed status information for complex aircraft that may feature a number of distinct components, for example to appropriately describe various high performance aircraft or airliners, child nodes could be used: | |||
<systems-modeling> | |||
<electrical></electrical> | |||
<hydraulic></hydraulic> | |||
<pneumatic></pneumatic> | |||
... | |||
</systems-modeling> | |||
=== Challenges === | === Challenges === | ||
edits