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.

The web page could look something like this

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.

This check will insure that the XML document is correct according to the version of the XML document it specifies. The orchestration validation will handle whether it is correct when made forward compatible and checked against the orchestration data values.

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.

Schema Provisioning

The XML schemas must be accessible to third party developers. Since the certification service will need to keep copies of all schema versions, it will also be able to act as the source of the XML schemas for third party developers.

Browser not supported