This document describes some recent refactoring of the W3C Schema processor which is part of the Schema Studio application. This processor turns Schema definitions into C# strong types ready to use in a development project.

1. i | P a g e
PROCESSOR REFACTOR
A Course Correction
D. Harrison
December 2023
© 2023, David Harrison, All Rights Reserved

2. Table of
CONTENTS
Introduction.............................................................................1
First Look ................................................................................3
Testing…Testing….....................................................................6
OTA_PingRQ ............................................................................7
Coming Next.......................................................................... 12

3. 1 | P a g e
INTRODUCTION
Since early Q2 2023, I have been refactoring the processor, an integral part of
the Schema Studio application.
In previous work, I focused on the lower-level XSD entities directly, a bottom-
up development process.
In the event, when approaching the entities at the higher levels, for example,
messages, the architecture of the processor was simply incompatible with the
deeply recursive forms involved. This nested structure is demonstrated in the
message definition of OTA_AirBookRQ, shown below:

4. 2
This basic incompatibility between the former code structure and what was
needed to fluently handle deep recursive structures led to a complete re-think
of how the processing needed to be performed. In this new approach, the
extensibility parts handle all the processing steps once the Structure Element
Repository is built in a first pass.
In developing this new top-down approach, the initial example used is that of
the message OTA_PingRQ (shown below), arguably the simplest message in the
Open Travel set.

5. 3
First Look
As a first look at the generated code from the processor which embodies this
new approach, below is shown a fragment of the code generated for the
AttributeGroup OTA_PayloadStdAttributes (the definition of which is shown in
the figure above) which is a key part of the definition of OTA_PingRQ:

6. 4
For the most part, the Attribute entities involved are reasonably
straightforward, e.g. EchoToken. However, those named Target and
TransactionStatusCode involve a SimpleType restriction expressed as an
enumeration. In such cases, the processor generates a generic Attribute
creation statement, where the type parameter is the internal, generated,
enumeration, e.g. Target_Enum.

7. 5
These generated, internal, enumerations, Target_Enum and
TransactionStatusCode_Enum, are shown below:

8. 6
Testing…Testing…
The types generated need to be validated via unit testing and the test for
OTA_PayloadStdAttributes is shown below:

9. 7
OTA_PINGRQ
The generation of the OTA_PingRQ involves two phases. The first phase deals
with the basic class structure and characteristics, and the second will cover the
Serialization/Deserialization aspects.
A fragment of the generated class appropriate to the first phase is shown in the
following figures:

10. 8

11. 9

12. 10
As in the OTA_PayloadStdAttributes case we need to ensure that our class
passes an appropriate set of tests. These tests are as shown below:

13. 11

14. 12
COMING NEXT
The target in this first phase of refactoring the processor that runs inside
Schema Studio is to generate a strong type class for OTA_PingRQ and this basic
form is shown in the previous section. The vital Serialization/Deserialization part
remains to be done, the documentation for which will be covered in a
subsequent article.
The next candidate will be the rather more complex OTA_CancelRQ, a definition
fragment of which is shown below:
In order the test a generated strong type for OTA_CancelRQ, we will need to
have available the following validated types:
Type Name Comment
UniqueID_Type ComplexType
OTA_CommonTypes.xsd
VerificationType ComplexType
OTA_CommonTypes.xsd
LocationType ComplexType
OTA_CommonTypes.xsd
PersonNameType ComplexType
OTA_CommonTypes.xsd
OTA_CodeType SimpleType
OTA_SimpleTypes.xsd
CancelRuleType ComplexType
OTA_CommonTypes.xsd
FreeTextType ComplexType
OTA_CommonTypes.xsd

15. 13
ContactPersonType ComplexType
OTA_CommonTypes.xsd
TPA_Extensions ComplexType
OTA_CommonTypes.xsd
OTA_PayloadStdAttributes -
ReqRespVersion AttributeGroup
OTA_CommonTypes.xsd
TransactionActionType SimpleType
OTA_SimpleTypes.xsd
StringLength1to64 SimpleType
OTA_SimpleTypes.xsd
NonNegativeInteger XSD Primitive
StringLength1to32 SimpleType
OTA_SimpleTypes.xsd
StringLength0to64 SimpleType
OTA_SimpleTypes.xsd
It should be noted that strong type classes, such as OTA_PingRQ and
OTA_CancelRQ, involve serialization/deserialization to XML methods as well as
the following methods and operators: Clone() and ToString() implementations.
Method/Operator Comment
Copy Constructor Instantiate a type from another instance
GetHashCode() Gets a type-related Hash code
Clone() A type-specific clone method
Operator == A type-specific comparison operator
Operator != A type-specific comparison operator
Equals() A type-specific equality method (used by the
comparison operators)
ToString() Provides a type-specific conversion to a string
form
These types also have an appropriate base class which offers properties and
methods common to all classes of a given type (e.g. ComplexType,
AttributeGroup, Element etc).