Abstract: XML schema allows the definition of business objects. A general term for an XML business object is a Module. This paper will describe the concept of a business object, and relate it to the XML module.

License Agreement: © 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.

The description and definition given in this paper will differ from the exact definition of a module found with other groups. However, the high level concepts will remain the same.

1.Introduction

The concept of an XML module is at the heart of the the architecture that is being used by OASIS, ebXML, and the UN/CEFACT committee [ebTechArch]. It has also been adopted by the ANSI X12 [ANSIX12]as the basis for their schema developments.

The key concept of this architecture is the XML module. In simple terms, an XML module is an encapsulated business object or business concept, expressed in XML schema.

The purpose of the POSC, modular architecture is to be able to capture a business object as an XML schema module.

2.What is a Module?

The above statement carries several “business objects².” Among them are the well, and the operator. These are characterized by being real-world things that have identities. It is clear that we will treat these as business objects and will develop modules to characterize them.

There is another candidate for a module - the production report data. This is a collection of information that must be transmitted. It can be thought of as a “table” of information. In the following sections, we will look more closely at whether this collection of information should be considered a module.

From the point of view of the OASIS, et al, groups with their characterization, these items would not be considered to be modules³. They would be characterized as an assembly of information. The assembly must be attached to a module for it to gain its full semantic meaning.

2.1.The Well Module

We will look more closely at the well as a module. The purpose is not to design a module, but to learn some of the basic properties of a module and how an application schema will pull them together.

The first thing to note is that a well has an identity. When something has a name, it is probably a business object. For a well, the name might be an API number (in the US), or a DTI PONS value (in offshore UK), or a local field name (like Bing Ranch #1). The main point is that one or more names can be assigned to it.

A second characteristic is that a business object will have properties. Examples of properties would be its surface location, its total depth, and various characteristics (eg, it is an active oil producer). Much of the technical detail of designing a module goes into what properties should be considered a part of this basic module, and what properties should be pushed off this list. For example, would the monthly production of a well be one of its properties? Would the list of formation tops be among its properties?

A third characteristic is that a business object will have relationships to other business objects. A well has an operator. A well has one or more owners. A well has various permits issued to it. A well may be located in a field.

An additional consideration is events. A well has events that occur throughout its lifetime. Examples of events would be regulatory approval, drilling, completing, workovers, sale, and abandonment. Since an event may be complicated, we may find that an event is a candidate for a module or its own.

An important point about a well module, or any module, is that it can be encapsulated. An exchange file could, for example, consist of a well module, and only a well module. A field could give a list of wells by referring to the well modules. The encapsulation concept allows us to a module as an isolated whole.

2.1.1.The Wellbore

Here is an issue that comes up with the well example. When analyzing the well business object in detail, we discover that a well may have more than one wellbore. One solution to this issue would be to pull out a wellbore as a separate module. Thus, the Well module would have one or more wellbore modules among its relationships. Whether or not the wellbore is pulled off as a separate module is a design issue that will not be dealt with in detail.

2.2.The Operator Module

When examining an operator business object, it becomes evident that a module will have more uses than simply as an operator of a well. Consider what a such a business object would look like. It would have the name (probably a company), a mailing address, phone numbers, possibly a particular person as a contact, etc.This same set of information would be useful to describe the well log service company. Or the drilling contractor. Or the shipping company.

Thus, the operator business object becomes generalized into a business associate - any person, company, or group that has a business relationship with another business object (such as the well).

It's use in the well module (and, for that matter, in any module) will be as a business associate, with the role of Operator. Note that this allows us also to use the same module for other roles. Thus, the Owner, the Sitting Geologist, the Service Company, all become business associates with their own roles.

The various characteristics of the well module (identity, properties, encapsulation, etc) are also true for this module.

2.3.The Production Data

The Production Data is also a candidate for a module. But it doesn't meet the characteristics set forth in 2.2. In particular, it does not have an identifier, and cannot really exist independently of the well and month for which it is relevant.

Because it is not a business object, and because a “table of data” [XMLTables] can be very complicated, we will not dwell excessively on this. We will note that, when building an application schema, we will often need to add the “table of data” to the schema to complete the exchange file.

3.The Application Schema and Templates

This section will describe how modules are gathered together, based on a template, to form an application schema. The application schema is the particular schema that is developed by a community of users to form an exchange specification.

3.1.Basic Steps

The template will define what is needed for an application schema. Based on the template, a community of users will select appropriate modules from a library of modules. When the appropriate modules are gathered together, they are profiled to fit the particular use that is being defined. The profiled modules, plus additional constructs, are gathered into a single schema, which constitutes the application schema.

3.2.The Template

The template is a statement, at a very high business level, of what business objects are needed to form an application schema. For example, the monthly production report for a well would need a well module (with its associated modules, such as a business associate module), a table of production data, and some kind of standard header and trailer information.

That's all there is to a template. It allows the business-oriented members of the community to state at a high level what is needed in the exchange. It also allows them to determine what is not needed. (Do we need the casing design? Do we need the formation tops?) Questions such as these are asked at the template level.

3.3.Select the Modules

Presumably, there would be a library of modules that are available for selection. When selecting the module, the user community would analyze the modules to insure that they carry the information that is needed. There is also the important criteria that a module may be well-accepted, and used in other exchange files. Thus, it would be sensible to re-use it for this exchange file.

Note the importance of the modular concept. If the modules are properly constructed, it would be possible to replace one with another, and still have a valid exchange file. The template may say, “Select a well module,” but it does not specify which one to select. The user community would determine which one is fit for purpose for the particular application schema they are developing.

Also note that a module selection may require another module. For example, the well module may need a business associate module (for the operator).

3.4.Profile the Modules

As a general rule, the modules cannot be used as-is. They are too broad, they offer too many choices, and they have slots which need to be filled in. The next step is for the users to tightly define how to use the modules [ProfilesAppSchemas].

For example, a well module may have an identifier (and a naming system). In the US, the community of users would specify that the particular exchange file would use the API number for the identifier, (with naming system = 'API'). In Norway, they would specify that you use their NPD form of identifier, (with naming system = 'NPD'). The profile in general limits the choices available in a general module.

There may also be areas where extensions are possible. For example, a well module may have a slot for “well business associates,” and the user community wants to have an operator, driller, and regulatory body recorded there. They would profile to select for these three roles, AND, they would be free to select an appropriate business associate module to serve as the business associate module.

Profiling a module makes it ready to use in the application schema. Properly done, it should reduce to a minimum the choices that an XML instance can make.

3.5.Tying things together

Finally a schema is developed that ties all these choices together. There may be some additional things that need to be added also. Usually, this schema is quite small, since the main work has been done in building the modules. The purpose of the application schema is to say how the various modules are structured in relation to the others.

It is important to remember that the template does not specify any particular module - only a type of module. The application schema, on the other hand, is a particular choice of modules, profiled to give as little flexibility as possible.

4.Summary Comments

A business object is a well-known thing to a business group. It has several characteristics, one of the most important of which is that it has a name (identifier). An XML module is an XML schema implementation of the business object. The modules are encapsulated descriptions of the business object, and may substituted for by other modules of the same type.

An application schema is formed by selecting the modules to be used for a particular exchange specification. The modules are profiled, and fitted together to form a coherent exchange set.

In addition, there may be structure (assemblies) that are not modules, but are often developed in a modular fashion (for example, tables of data). These may also be necessary for an exchange set, but are usually not interchangeable.

5.References

5.1.Outside References

[ANSIX12] X12 Reference Model for XML Design, 2002-10, produced by the ANSI X12 committee, obtainable at http://www.x12.org/x12org/.

[ebTechArch] ebXML Technical Architecture Specification V1.0.4, 2001-02-16, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/ebTA.pdf.

[FedTagStds] Federal Tag Standards for Extensible Markup Language, 2001-06, produced by LMI, not obtainable from the internet.

[HKGuide] XML Schema Design and Management Guide, (4 parts), Draft versions dated in summer, 2003. Produced by Hong Kong Information Services Technology Division. Available at http://www.itsd.gov.hk/itsd/english/infra/eif.htm.

5.2.POSC References

1© 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.

2In this paper, we will talk about business objects as things that exist, regardless of how they are expressed. If a well is a business object, we can have a well as it exists in the mind of an exploration manager. We can have a well as implemented in a relational database. Etc. If a business object is implemented as an XML schema construct, we will refer to this implementation as an XML module, or more simply, as a module.

3Actually, it is not clear how they would classify it. There are some ambiguities in their definitions, since they don't consider the transmission of “tables” of information.

2003-07-18 Introduction to Modules Page 5 / 5