The Business Integration -- Information Conformance Statement (BI-ICS) 1.0 specification has now been updated and replaced by the Business Information Conformance Statement (BICS) 2 specification. For more on this update, read Scott Hinkelman's article "Service information constraints with BICS 2" here on developerWorks.

This short article focuses on XML-based business information modeling, however the general issues discussed are fundamentally neutral and not technology-specific. The discussion is intentionally terse, as much industry writings have already been published on the subject. I focus on discussion around the realities and the need for declaring comprehensive conformance of information, and introduce the Business Integration -- Information Conformance Statement (or BI-ICS) specification to help solve the problem while referencing industry discussion. This specification addresses the need for business partners to declare information conformance to well-known type systems and processes in order to facilitate different constraints that vary depending on how the information is used.

Minimal agreement

Standards groups are fundamentally about agreement. This is the case regardless of whether a standards organization is focused within a specific industry or more horizontally (such as interaction infrastructure). However, within the current IT standards landscape that's focused on B2B interchanges, the higher-level efforts (above the horizontal infrastructure standards efforts) are usually focused on common business structures and industry-specific documents. This level of agreement on standards is arguably more difficult to achieve as the standards become directly relevant to the business stakeholders and the processes involved.

Several current trends in industry-level standards groups are relevant to this vertical, or business-level perspective. In fact, some continuing trends are not new, reflecting difficult problems which have been in existence since EDI standards emerged. One specific trend is that of "loosely-defined" industry XML standards, where the cardinality structure of the formal adherence mechanisms, such as DTD or W3C XML Schema, is minimally defined. This is common practice in industry-level standards consortiums such as The Open Travel Alliance (OTA), HR-XML, MedBiquitous, and many others (see Resources). This can result in XML document specifications in which many business structures are formally specified as being optional. The business reasoning for this is almost always justified, as the different participating business partners currently have, and will continue to have, different information requirements. This is especially true with standards that are oriented toward message interchanges; however, the end result is usually significantly diminished interoperability expectations at the business level when such standards are used alone.

Back to top

Aggravated by absence of usage context

To further aggravate this situation, many industry-level standards organizations define business documents independent of defining specific uses for the information -- again for justified business reasons. Defining business information documents outside of a usage context may in itself be a logical approach when considering delegation of the actual usage onto underlying infrastructure. In this case, the approach becomes consistent with infrastructures such as Web services, where the actual usage of the information is in practice represented as WSDL (see Resources) operation names. This usually results in multiple usages for a common business schema. For example, a single schema containing member information for an organization, including member identifiers, may be used for both creating and retrieving information about a member -- with significantly different information required for each operation. The schema would define large amounts of information. Such information may not only be optional, but may not even be relevant for a particular use of it, such as in the retrieve operation where only the member identifier would be required.

These situations, while justified in practice, emphasize the need for alternate, or additional, information constraints for a given use of common information schemas. The ability to formally specify, or make a statement about, increased information constraints beyond open industry standards at a partner-to-partner level is both pragmatic and a desirable aspect of business integration, and can increase interoperability at the business information level.

As an alternative, some industry groups take responsibility to define usage contexts (sometimes called verbs) along with the relevant (potentially all) business information (sometimes called nouns) in order to facilitate an increase in interoperability. The Open Application Group (OAGIS) is an advanced organization that takes the approach of using an architected payload schema design. It supports a multistage validation mechanism based in Schematron (see Resources) assertions to accommodate increased information constraints. However useful or advanced this approach is, it is not yet enough to declare, or make a statement about, what partners need to insure a high degree of business-level interoperability. The OAGIS approach is arguably the most advanced in the industry, but it does not define a formal mechanism that allows for the declaration of comprehensive information conformance. The BI-ICS specification provides this ability.

The BI-ICS specification is complementary to the approach of designing information independent of usage context, and to approaches such as OAGIS.

Back to top

Aggravated by XML Schema shortcomings

Industry groups that make use of XML Schema's powerful information modeling capabilities are also restricted by its inabilities, such as the inability to specify validation checks based on instance element values. This situation further aggravates the decline in interoperability at the business information exchange level. Will Provost outlines this situation in detail (see Resources) and further covers the area known as multistage validation. He also discusses XSL transforms through various approaches.

Back to top

The need for increasing interoperability through stages

Most industry-level standards organizations are incapable of providing standards that allow for complete interoperability between all of their involved partners. Recognizing this results in a realization that interoperability is likely best achieved through increased staging, or leveling, of conformance toward peer-to-peer partner relationships. Consistent with this reality of industry-level standards consortiums, the industry in general needs to formally address this situation through standards. Specifications that allow the declaration of comprehensive conformance for business information of many types are needed across many industries. Ultimately, standards in this area which allow alterations in constraints beyond those defined in large standards organizations will increase business-level interoperability at a partner-to-partner information exchange level.

The BI-ICS specification is targeted at providing such statements of information conformance.

Back to top

Formally stating conformance with BI-ICS

Moving toward standards in this area is a prime motivation for this article. To that end, the BI-ICS specification is introduced here. BI-ICS allows for a formal declaration of business information conformance through an extensible XML vocabulary. BI-ICS provides the ability to declare that business information is conformant with type systems and processes.

Specifically, BI-ICS intrinsically supports the declaration of a sequential conformance model with specific W3C XML Schema instances, MIME types, and XSLT transforms based on Schematron assertions. BI-ICS is extensible for extended support of alternate type systems, process mechanisms, and conformance models.

The actual application of BI-ICS is beyond the scope of the specification, however many uses of BI-ICS are possible. The following are some possibilities for using BI-ICS:

• Inclusion as agreeable content into various forms of trading partner agreements
• Referenced in use cases or interface definitions to define business information constraints
• Advertised in e-business registries for publishing expected information constraints
• Used by infrastructure runtimes to provide conformance checking prior to handoff to upper-level applications

This article has introduced the BI-ICS specification as a step toward a solution for increasing interoperability at the business information level. BI-ICS provides a formalism based in the need for differing information constraints beyond industry-level standards, and the ability to declare conformance of information based in a variety of formats. A standardization of the BI-ICS specification would help increase business interoperability and define a foundation for future related specifications in this area.

The BI-ICS specification is available online. An emerging implementation for BI-ICS is available on IBM's alphaWorks as "BI-ICS for Java" (BI-ICS4J) - - see Resources.

Resources

• Read Business Integration -- Information Conformance Statements (BI-ICS), the BI-ICS specification.
  
  
• Download BI-ICS for Java (BI-ICS4J) from IBM alphaWorks, a Java implementation of the BI-ICS specification.
  
  
• Find out more about the Open Travel Alliance (OTA), which offers open e-business specifications for the travel industry.
  
  
• The HR-XML Consortium (HR-XML) develops and promotes standardized XML vocabularies for the human resource industry.
  
  
• Read about MedBiquitous, which develops collaborative technologies for medical education.
  
  
• Check out the Open Applications Group (OAGIS) which focuses on promoting interoperability among business applications and creating business language standards. Additional background can be found in this developerWorks article by Michael Rowell, chief architect for the group (June 2003).
  
  
• While you're at it, you may want to investigate Schematron, an XML structure validation language that uses patterns in trees. OAGIS supports a multistage validation mechanism based in Schematron assertions.
  
  
• Read the Web Services Description Language (WSDL) specification on the W3C site.
  
  
• In "Beyond W3C XML Schema" by Will Provost, explore XPath and XSLT for validation.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Minimal agreement
• Aggravated by absence of usage context
• Aggravated by XML Schema shortcomings
• The need for increasing interoperability through stages
• Formally stating conformance with BI-ICS
• Resources
• About the author
• Comments

Dig deeper into XML on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers