The XML certification service will have two user interfaces. The first will be used to assist interfacing systems and developers with the mechanics of their XML interface. It will be the most used part of the service because having valid mechanics will be a prerequisite to the second part, and checking mechanics will occasionally be necessary for production XML documents that fail for one reason or another. The interface will have detailed information about the XML document and any problems or issues with it.

The second part of the service will valid the correctness of the third party software solution for the specified orchestration scenarios. This part of the service will assume that the XML is well-formed and valid, i.e. the things checked by the first part. The checking of correct orchestration will require that the service knows what scenario is being checked. It will validate that the proper data is provided to meet the reporting requirements of the scenario.

XML Validation Service

User Interface

The user interface will have several components.

• XML File Input - this will be a file input field that allows the user's XML file to be uploaded for checking.
• XML File Display - This will be a section of the page where the contents of the file are displayed back to the user along with line numbers. Text that is associated with errors can be highlighted or color coded.
• Message Log - This section of the page will display messages about the XML, with line numbers that correlate to the file display section.

Functional Checks

The functional checks in this section identify the elements of XML mechanics that will be checked and reported to the user.

Recognized Encoding

The system will read the bytes of the file and will check for valid encoding. The system will accept 3 types of encoding.

• UTF-8 - If the XML starts with the standard less than sign it will be assumed to be UTF-8, which is equivilent to ASCII single byte characters.
• UTF-8 with Byte Order Mark - If the XML is actually encoded as UTF-8 it may optionally contain a 3 byte Byte Order Mark. This BOM is meaningless in eLandings XML documents since only single byte characters are expected, but if present it must be recognized as the BOM.
• UTF-16 - If the XML starts with a 2 byte Byte Order Mark, indicating big endian or little endian, then the data is encoded in a double byte character set, and will be treated as UTF-16 encoded data.
• Other - if the data is anything else it will be logged as incorrectly encoded and no further checks will be made. If a recognizable encoding attribute is included in the text that will be noted in the messages.

Encoding Attribute Consistency

The XML preamble element includes an encoding attribute. This must match the actual encoding of the file. If it does not the inconsistency will be logged and no further checks will be made.

Formatting

Before the XML is checked for well-formedness, it will be formatted. This will make references to problems more consistent and straightforward. Formatting will consist of line breaks after element closures, and indenting.

Well-Formedness

The XML will be checked to insure consistency with the XML specification. In particular, it will be checked that all tags have matching close tags.

Schema Validation

The XML will be checked against the XML schema. This will check for the presence of required elements and the absence of unknown elements, even if well-formed.

Schema Version

Since the eLandings system allows the import of XML documents created with legacy schemas, the validation service will have to honor those schemas when checking schema version compliance. Otherwise, if a user has a document created with an older schema they will not be able to validate it with the service, and that will lead to production support calls.