This is the parent structure of the XML file. It contains all of the information necessary to generate the 8007 conformant output and the C++ files. This is the name of the test suite. A test application can use this value to distinguish this test suite from others. This section identifies the functions that are called by the test procedures and which must be implemented by any system wishing to implement the procedures One specific function The value to be compared If the variable references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. The boolean comparison operator The value against which value1 is compared If the variable references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. This is a value (typically by reference to another variable) which should be displayed to the user so that a proper judgement can be made. If the variable references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. Used for comparisons using simple boolean logic Indicates whether the comparison values are combined using AND or OR logic A logical comparison resulting in true or false This is a value (typically by reference to another variable) which should be displayed to the user so that a proper judgement can be made. If the variable references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. This is the question to be posed to the user to decide Pass or Fail This is any additional text that should be displayed to the user A textual description of the variable. The name of the directory to connect to The user name to use in the connect process The password to use in the connect process The file on which the operation is to be performed The directory to be retrieved An indication of any file names that should contained within the list The file specification for files that should be contained in the list response (e.g., *.jpg) The number of files that should match the file specification within the list The file to be renamed The new file name The name of the function in a format that conforms to mainstream programing conventions (e.g., no spaces or special characters) The return value for the function; a widely recognized data type A parameter for the function call A detailed textual description of the purpose of the function describing the inputs and outputs A sample C++ implementation of the function The name of the function to be called to conduct the comparison The text to appear to describe the comparison in the test procedures The list of arguments to be passed to the function Indicates whether a response is expected for a GET, GET-NEXT, or SET request A bitmapped integer value that represents the valid error values for the response to a GET, GET-NEXT, or SET request. If a bit is set, the error response is allowed. Bit 0 is noError, Bit 1 is tooBig, bit 3 is noSuchName, bit 4 is badValue, bit 5 is readOnly, bit 6 is genErr. Thus a value of 3 indicates bits 0 and 1 are set, which means the response may be either noError or tooBig. The dynamic object number for STMP requests A variable referenced by the step. The type of variable is dependent upon the type of step. A GET, SET, or GET-NEXT step should refer to one or more objects from a supported MIB. A CALCULATE, RECORD or CONFIGURE step should reference one or more variables, which are used to store values within the test procedure logic. A FOR EACH step should reference exactly one variable, which is the logical variable that steps through the range of values defined in the for each clause. The other step types should not include a variable structure. The data type of the parameter; this should be a widely recognized data type The name of the parameter using mainstream programing conventions Each test case is defined in its own section of the file. This is an integral identifier for the test case that is unique within the containing XML file. Each test step will reference this identifier as its 'linked-test-case' to unambiguously identify its parent. It is not used for the 8007 output. It is used in the C++ code to assign each test procedure within a test suite a unique integral number. The NTCIP 8007 Test Number that is used to indicate the location of the test case within the overall hierarchy of all tests (i.e., it is the last portion of the clause number of the test case). Whereas the ID is an integer; the number allows a dotted notation (e.g., 2.3), allowing tests to be grouped. Within the 8007 document, this is used as the last portion of the clause number of the test case. The tag is a descriptive textual name for the test case that conforms to most scripting naming conventions (e.g., a string of less than 33 characters with no spaces, periods, etc). It is used in Code to reference the test case. The NTCIP 8007 Title of the test case. The NTCIP 8007 Test Case Description. The NTCIP 8007 Notes field for the test case. The steps of the test procedure A unique integral identifier of the step within the subject test case. All steps of the test case should be listed sequentially within the file. The unique identifier of the containing test case. This is in fact redundant, since the step is contained within the test case, but is provided for consistency with relational databases. The NTCIP 8007 step number. The XML file format further constrains this number to be a dotted value indicating its position within a step hierarchy. The step hierarchy is always sequential, except for: (1) the steps of the true branch of an IF statement are indented from the IF statement (2) the steps of the false branch of an IF statement are indented from an ELSE step that immediately follows the IF step (the resulting ELSE step never explicitly appears within the NTCIP 8007 output), (3) the steps of a DO...WHILE statement are indented from the DO...WHILE statement (and NTCIP 8007 documentation has the anomaly that the dotted numbers appear before the parent IF clause), and (4) the steps of a FOR EACH loop are indented under the FOR EACH step. If this step is indented under another step (e.g., the step is a part of an IF branch), this field shall be present and indicate the step-number of the parent step (i.e., containing branching or looping statement). Boolean value indicating whether or not this step is a SET-UP step per the NTCIP 8007 keyword. The name of the variable. If this is a GET, SET, or GET-NEXT request, this should be the name of the MIB object with an instance identifier. Otherwise, it is the name of the logical variable referenced in the test procedure. A textual description of the variable. This is the value (either explicitly or by reference to another variable) which forms the first term in the equation. If value1 references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. The mathematical operator which describes how value1 and value2 are to be processed This is the value (either explicitly or by reference to another variable) which forms the first term in the equation. If value2 references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. This is the value (either explicitly or by reference to another variable) to which the current variable should be set. If the variable references a MIB object from the previous GET, SET, or GET-NEXT step, this is the zero-based position of the referenced object in the response. The location where the value to be inserted into this field should be defined. In many cases, this will be a reference to a specific clause of the PRL, but may reference the project specifications or test plan. A textual convention that defines the data type The minimum value allowed to be assigned to the variable (i.e., minimum of the range). The maximum value allowed to be assigned to the variable (i.e., maximum of the range). This is the default value that the test case should use, if the user does not explicitly define a value to use (which they should). The name of the function to be called A legacy field that contains computer code that implements the desired logic. This should not exist in a fully converted file Indicates the required syntax for the variable. One of osInteger, osCounter, osGauge, osTimeTicks, osOctetString, osOID, osIPAddress, osOpaque. An indication of the format in which the value is shown for the given syntax. Possible values are: ofDecimal, ofAscii, ofOID, ofIP, ofHex, ofEnum This is the value (either explicitly or by reference to another variable) to which the current variable should be set. If the format is defined as ofEnum, the value field shall be set to the textual name of the enumerated object in single quotes (e.g., 'value') and the integer value assigned to the enumerated value will be recorded as the value-position. The 8007 documentation will reference the textual name, whereas code is more likely to need the integral value. A textual convention that defines the range of values allowed for the variable. For example, the name UBYTE might be given to the range of 0..255 The minimum value allowed to be assigned to the variable The minimum value allowed to be assigned to the variable