The certification of a data producing product such as an electronic logbook requires that it meet standards, business rules, and expected results.
We assume that the data will be exchanged in XML files.
The layers from the most concrete to the most abstract are:
- Encoding - is the XML file encoded correctly. The top level element includes an encoding attribute, the file encoding must match that attribute. The eLandings system accepts UTF-8 encoding, with or without the Byte Order Mark, and UTF-16 encoding, which always includes a 2 byte Byte Order Mark. Currently it does not check if the encoding specified in the top level element is the same as the detected encoding.
- Well-formed XML - does the XML file meet the standard of XML. Does each tag have a closing tag, etc. Prior to the well-formedness check, formatting and indenting are highly desirable. Otherwise, if the user has produced a file without newline characters the messages will refer to line 1, with a high column number. These messages will be less useful to the user
- XML meets Schema - does the structure of the XML file adhere to the XML schema for the particular exchange. This layer needs to comprehend changes in the XML schema over time. Does the data in the XML document match the data type rules specified by the schema.
- Data meets Business Rules - does the data in the XML file meet the requirements of the business rules in terms of required data, rules for data content of each elements, and rules for how the data elements interact.
These layers are checked both in the certification of a product and each time data from the product is submitted to the acquiring system. That is, the XML must be valid and the data must pass the business rules each time data is submitted. - Data meets Scenarios- The certification service has another layer that should be considered and tested for during the certification process. This is the logical scenario layer. The testing in this layer is more difficult to conduct unambiguously. Scenarios must define circumstances related to fishing and processing that rigorously define inputs to the data producing product, but do not specify how the data should be represented in the XML. (Those rules should be available elsewhere.) The certification service needs to be able to interpret submitted data to insure it correctly represents the circumstances of the scenarios, since the same logical data could be reported in multiple ways. For example, 1000 pounds of H&G halibut could be reported on one itemized catch line as 1000 pounds, or 10 itemized catch lines as 100 pounds each.