Compiler Usage

The BGL compiler is invoked with the command:

About the XML Format

The scenery format is XML-based and follows a strict file structure with regards to element hierarchies, case sensitivity, and the contents of elements (potentially including white space).  XML is a text-based file format consisting of elements and attributes.  The XML specification also allows for comments, to allow scenery files to be annotated.  At this time elements, attributes, and values are all case-sensitive.  The XML convention used is as follows:

1. All significant words in elements capitalized.
2. The first letter of an attribute is not capitalized, but the successive significant words are.
3. All letters of an attribute ‘value’ are capitalized (unless otherwise specified) and words are separated by underscores.
4. It is OK to include blank lines in the XML files to improve readability.
5. The order that attributes appear for any one object is arbitrary.
6. The keywords "YES" and "NO" have the same meaning as "TRUE" and "FALSE".

Scenery File Format

The following is a sample of the XML file structure used for scenery files.  Note the use of ‘<!--‘ and ‘-->’ to start and end comments. 

• The first line of the file indicates the XML version and character encoding to use for the rest of the file.  This line is not strictly required by XML parsers, but is strongly recommended to ensure the XML parser produces expected results.

• The second indicates the start of the data.  The tag FSData is considered an element and indicates what kind of data is present in the file. 

• Following the FSData tag is an attribute: version.  Attributes are immediately followed by a value enclosed in quotes.  For scenery, the FSData element must be followed by a version attribute and that version must be "9.0". This number is consistent with that used in prior versions of this engine, as the format has been added to but not changed significantly.

• The remaining attributes on the line are directives to the XML parser that tell it how to validate the contents of the XML file.  These attributes must be present in all scenery XML files and match the above sample.  Once all of the attributes for the FSData elements have been specified, the element is closed with ‘>’. 

• Following the declaration of the FSData element will be the XML that defines the contents of the file.  In this example the file content is simply a comment. 

• To finish off the file, the </FSData> element is specified. 

Both facility and scenery information may be contained in a single .XML source file and this practice is encouraged.

Common Errors

The XML compiler has been designed to be very strict in an effort to avoid ambiguity.  As a result, the strings used for XML elements and attributes are treated as case-sensitive.  The compiler will report such errors at compile time.

Some scenery elements are not allowed to contain other sub-elements.  The form of the XML is used to distinguish between these types of elements. 

Elements allowed to have sub-elements take this form: 

Elements not allowed to have sub-elements take this form: 

If an element that is not allowed to have sub elements isn’t closed with ‘/>’ or contains any data (including white space) before the closing element tag, the following error will result:

The XML standard is very strict in this regard and it is essential to have the proper closing on an element. If the element is allowed to contain data, the element is closed with a declaration of the element prefixed with a ‘/’ character (i.e., </ClosingElement>).  If the element is not allowed to contain sub-elements the declaration is closed with ‘/>’.  This is an important distinction that will be checked during XML validation.  The appropriate structure of these elements will be shown in their descriptions.

 When errors are reported from the compiler, they generally start with the line number and character position on the line where the error occurred.  This format is mainly used when an XML format error occurs and sometimes when a data content error occurs. All of the .XML content is validated against an .XSD to ensure proper file structure before processing in the compiler.  As a result, ordering of sub-elements is verified.  If elements are found to be out of order, the following error will result: 

 This is .XSD validation code reporting what it expects to see next.  Check the XML at the line noted and see if there is an element that might be out of order, or whether multiple instances of a sub-element are allowed.