This section describes the process involved in developing a DEX.

At a high level, the development of a DEX can be broken down into three stages:

1. Why: Establishing "why" data is to be exchanged. This requires an understanding of the business processes to be supported and information needed by those businesses. For example, if a car is on a long term lease and the servicing of the car is contracted a maintenance organization, the maintenance organization will require information about the odometer readings (mileage) of the car so that the servicing of the car can be planed by the organization. It is not necessary to understand the detailed business processes of the organizations involved in the exchange, but sufficient knowledge of the business to identify the reasons or any exchange.

2. What: Having established that there is a high level need for exchange data between organizations, it is then necessary to define "what" information is to be exchanged - the "information needs". This involves detailing the information at a business level, and typically involves the definition of a business object model. This provides a specification of the information that is to be exchanged.

3. How: The next stage is to define "how" the standard is to be used to exchange the data. This requires the business level information to be mapped to the equivalent information in the standard.

The three stages outlined above are represented within a DEX, the components of which are summarized in DEX overview and shown in Figure 1. The corresponding DEX sections are:

1. Why: This is documented in the DEX as part of the introduction and activity model. For example:
   • DEX Exemplar:ConsumptionOfLife: Introduction
   • DEX Exemplar:ConsumptionOfLife:Activity model

2. What: This is documented in the DEX as part of the "Scope", "Business Overview", "Business Information Overview" and "Business Information Model" sections. For example:
   • DEX Exemplar:ConsumptionOfLife: Scope
   • DEX Exemplar:ConsumptionOfLife:Business Overview
   • DEX Exemplar:ConsumptionOfLife:Business Information Overview
   • DEX Exemplar:ConsumptionOfLife:Business Information Model

3. How: This is documented in the DEX as part of the "PLCS PSM Representation", "Templates", "Schemata" and "Reference Data" sections. For example:
   • DEX Exemplar:ConsumptionOfLife: PLCS PSM Representation
   • DEX Exemplar:ConsumptionOfLife:Templates
   • DEX Exemplar:ConsumptionOfLife:Schemata
   • DEX Exemplar:ConsumptionOfLife:Reference Data

The steps in developing the DEX are therefore:

• Define scope:

  In order to clearly bound the Data Exchange requirements a scope statement should be clearly defined. It is recommended that a bulleted list of those concepts deemed to be in scope and anther covering those concepts out of scope should be developed.

• Business overview:

  The high level business view of the required data exchange should be specified in terms of:

  • Business process - A view of the actors involved with the exchange and a clear understanding of the context for the exchange(s).
  • Business information overview - A conceptual representation of the concepts making up the exchange and their relationships.
    NOTE    Ideally this will not be an attributed model, that is defined later.
• Business information model:

  This should be a fully attributed information model formally defined using a recognised modelling language such as UML or SYSML. The model should be developed using terminology appropriate for the business context. By being fully attributed it allows translator developers to use this as a reference model for the exchange context and it provides the required level of detail to allow context specific templates to be developed.

• PLCS PSM representation

  This activity uses the Business information model to guide the selection and development of templates needed to support the exchange requirements.

  • Template creation
    • Identify those from OASIS - Some concepts required by the Business intormation model may be directly supported by concepts within the PLCS PSM or OASIS templates already available. If so these should be used directly.
    • Create required templates - If templates don't exist, then new templates should be created following guidance provided in . If the required templates are of a general nature, then they should be developed as OASIS templates. If the templates are specific to this context then they should be based directly on the Business objects found in the Business information model, reflecting those object and attribute names.
  • Block definition diagrams:

    Once all appropriate templates have been developed they should be combined to provide equivalent model(s) to those specified in the Business information model. This allows verification that all concepts required by the Business information model have been met by the identified templates.

  • Reference Data development:

    Within a context there is a need to identify reference data that has significant meaning for that context. This reference data is often in the form of identification and naming schemes used and as such should extend the OASIS standard reference data concepts to cover these context specific concepts. Reference data can be identified from a number of sources:

    • Identify sources - Within the context standard naming and identification schemes are usually documented. These should be considered for translation into OWL based RDL if they are not too large.
    • Identify requirements for reference data from templates - In many cases when a context specific template is developed it builds upon an OASIS template. These OASIS templates will already have Reference data specifications, that can either be used directly or extended in this context.
• XSD Generation

  Given that the DEX defines a usage profile for the PLCS PSM blocks it is likely that not all concepts in the PLCS PSM are required in this DEX. Therefore the XSD defined for the whole PLCS PSM can be subsetted resulting in a smaller specification required for implementation. This DEX specific XSD generation should be automated based on the template specifications.

• Example data sets

  Finally to verify that all concepts are handled correctly each exchange identified within the Business process model for the DEX should have a fully populated test data file developed for it. This allows the template developer to provide this verification and also provides sample files for the developers of translators based on this DEX specification.