Responses to CICA Criticisms

Many have discussed and critiqued ASC X12’s Context Inspired Component Architecture (CICA) since well before it was codified in the X12.7 standard. This is part of the normal development and market evaluation of a standard. However, one set of criticisms, primarily voiced by Mark Crawford, currently of SAP but formerly with the Logistics Management Institute (LMI), has persisted over the past few years. Many of these criticisms were included in LMI’s comments in the balloting of the first version of X12.7, including several that appeared to be an inaccurate or confused reading of the proposed standard. They were answered then formally in an Open Forum at an X12 trimester meeting, and later informally in an e-mail to LMI. However, several have persisted. Mark reports that he hasn’t said much about CICA in the past year or two, but in the last few months another set of remarks attributed to him came to the attention of the X12 leadership. I was asked by Dan Kazzaz, the X12 chair, to respond. I invited Mark to confirm his original comments and remark on my responses. While he did review a draft of this article, Mark declined to comment publicly, asking that I report "I don't think it would be appropriate at this point for me - as an SAP employee - to publicly comment on statements attributed to LMI." I regret his decision. (By way of background, Mark and I first became acquainted during X12’s original work on XML and he served as my vice-chair on the ebXML Requirements team. While I find many of his criticisms to be unfounded and inaccurate, I still respect him and regard him as a friend.)

The original criticisms, either as quotes or summaries of comments, are marked as "CRITICISM". My responses are identified as "RESPONSE". The primary source of these criticisms is a 2004 Blue XML (an XML work group of the Blue Cross/Blue Shield associations) entitled "CICA Observations - June 2004" and attributed to Mark Crawford. The comments are largely in relation to CICA conformance with UN/CEFACT's Core Components Technical Specification (CCTS).

While my comments were reviewed by colleagues in X12’s Communications and Controls subcommittee, they are my own comments and should not be interpreted as statements of ASC X12.

Notes on abbreviations:

• ASC X12 – Accredited Standards Committee X12, accredited by the American National Standards Institute (ANSI)
• CC - Core Components
• CCT – Core Component Type
• OAGi - Open Applications Group, Inc.
• OAGIS – The XML business specifications produced by OAGi
• OASIS - Organization for the Advancement of Structured Information Standards
• SDO – Standards Development Organization
• UBL – Universal Business Language. Both a standard and a Technical Committee of OASIS
• X12C – The Communications and Controls Subcommittee of ASC X12

1. Supplementary components

The CC metamodel requires a minimum of one supplementary component for each CCT. However, CICA allows for "zero or more" supplementary components (Sec 4.1 Primitives).

In regard to the first version of X12.7 approved in June 2004, this is accurate, and was regarded as an oversight at the time. The June 2005 version of X12.7 corrected this. Sections 3.1 and 4.1 now read "one or more supplementary components."

2. Naming of constructs

There exists many unnecessary name differences between CICA and CCTS, and with the CCT constructs. Also, this naming and construct difference is not limited to CCTs but permeates the entire structure of the proposed CICA architecture.

This comment does not take into account the fact that the names are different because the underlying semantic concepts are different. For example, the CCTS only defines one type of aggregate construct for Core Components and Information Entities. CICA defines five types of constructs that correspond to aggregates: components, blocks, assemblies, modules, and documents. There are five types because they have different semantic characteristics.

That said, the relationships between CICA constructs and the corresponding CCTS constructs are not specified in X12.7. Several people in X12 regard this as a deficiency and are working to make the correspondences explicit in a future version of X12.7

3. Justification for facet restrictions

The list of allowed facet restrictions for each datatype is not justified or explained.

X12.7 is a standard. Typically, most specifications and standards, not just those of X12, do not contain justifications for design decisions. They only specify. X12.7 contains no justifications for any of the design decisions. The facet restrictions on datatypes are no exception.

4. White space facet

The handling of white space as a facet restriction is not addressed

Part 5 of X12.7 specifies the W3C schema language representation of CICA. It only addresses the minimum set of schema language features required to represent CICA. The W3C XML Schema Language is very rich in features, and there are many that are not addressed at all in X12.7. In relation to this specific criticism, during X12.7 development there was no business requirement expressed which might be implemented through the use of the whiteSpace facet. If, in the future, such a requirement is raised in X12 that facet is likely to be addressed.

5. Alignment with OASIS xsd:baseTypes

The xsd:baseType for several CCTs differs from what has been published by OASIS in agreement with UN/CEFACT and OAGI.

ASC X12 has in the past aligned with UN/CEFACT and ISO where possible. However, X12 has not formally stated any intention to align with XML naming and design rules or any other standards developed by the OASIS UBL TC. Further, at the time that this criticism was made the xsd:baseTypes for CCTs did not even have any status as an officially approved standard or specification. X12 traditionally has not referenced in their standards the standards of other SDOs until they have been approved by their respective owners. X12 is currently reviewing UN/CEFACT's XML Naming and Design Rules, with the intention of moving toward alignment in a future version of X12.7.

6. Class property names

The names created for class properties are not semantically unambiguous.

I understand this criticism to mean that the names of properties of classes of business objects (CICA constructs created in conformance with X12.7) are not guaranteed to be semantically unique. The criticism, in effect, alleges non-compliance with ISO 11179 conventions for property names. That ISO standard provides a set of rules designed to reduce semantic ambiguity among names. The CCTS follows ISO 11179 in this regard.

X12.7, in section 4.10.1, states:

"In general, item names (such as assembly_name and block_name) and usage names (such as block_usage_name) shall conform to the rules for constructing the "property term" as defined in the UN/CEFACT ebXML Core Components Technical Specification. The item name SHOULD in most cases be more general than a usage name, since the usage name represents an instance of the item when used in a larger construct. In most cases, the property term SHOULD correspond to a common business term."

If X12.7 is deficient in this regard, then so is the CCTS upon which it is based.

7. Use of numbers as part of a name

The use of numbers as part of a name violates XML best practices.

The currently approved versions of X12.7 specify that sequence numbers shall be appended to the names of abstract constructs (assemblies, blocks, components, and primitives) to form the names of the corresponding concrete constructs. For example, the first concrete block derived from the abstract block "Service Method Block" is named "Service Method Block_1". Most of the contributors to X12.7 agreed that this is a somewhat awkward naming convention, but we could not come up with a better one at the time. Concrete constructs are intended to differ from abstract constructs only in relation to restrictive properties, not semantic qualities, so an arbitrary numeric identifier seemed as appropriate as anything else. However, this approach is under review for future revisions of X12.7.

Names of concrete constructs are used as complex type names in the schema language representation of CICA. The example would yield a complexType named "ServiceMethodBlock_1".

Numbers as part of an element or attribute name are allowed in the XML recommendation, and as the names of simple types, complex types, and other constructs in W3C’s XML Schema Language. There are many different concepts of "XML best practices", and I’m sure there are other aspects of CICA’s use of schema language which run afoul of someone's idea of best practices.

I do not regard this as a significant criticism of X12.7.

8. Versioning approach

No clarity on what the CICA versioning approach is

A versioning approach is currently beyond the scope of X12.7. It is addressed in X12's "Standing Document 2 Operations Manual, Development and Maintenance Procedures". Basically, a new version is released when X12’s Procedures Review Board approves it for publication. Versions are process and calendar driven in X12, unlike some other bodies in which version and release designation are based on changes in particular characteristics of the standards, schemas, or other objects. In this regard, the CICA versioning approach is the same as X12's approach to versioning its EDI standards based on X12.5 and X12.6.

I do not regard this as a valid criticism of X12.7. That said, X12C has recently begun work efforts to make CICA more compatible with XML Web Services applications. Various issues regarding versioning have arisen in those discussions, particularly in regard to minimizing the disruption of CICA version upgrades in web services environments. X12.7 may be revised in the future to resolve these issues.

9. Namespace approach

No clarity on what the CICA namespace approach is

Section 5.1 of X12.7 clearly specifics how CICA namespaces are named. The root part of a document’s namespace is based on the CICA version. The approach is expressed in very few words, but it is very clearly and unambiguously specified in Backus-Naur Form notation.

10. Required documentation

No clarity on required documentation for each XML construct

This is an issue in regard to the X12 standards development process and as such is beyond the scope both of X12.7 and of CICA as a semantic architecture. Documentation requirements during the development of CICA constructs are primarily specified by SD2 and the procedures of X12's Technical Assessment Subcommittee (X12J), and secondarily by X12's secretariat, the Data Interchange Standards Association. This is not a valid criticism of CICA or X12.7.

11. Use of schema language features

Many of W3C XML Schema Definition Language elements are not covered in the CICA document.

See comment above in relation to #4 regarding the white space facet. This is not a valid criticism of X12.7.

12. "Proprietary"

CICA is described as a "proprietary" architecture.

The prevailing use of "proprietary" in the IT industry applies this adjective to standards and technologies that are unique to a single company, a commercial entity. This is most certainly not the case with CICA. X12.7 was developed as a standard of X12, an Accredited Standards Committee of the American National Standards Institute.

Aspects of CICA, as specified X12.7, may be considered as targeted for use by X12 specifically rather than by any organization in general. For example, the namespaces specified and specific sequence numbers are unique to X12. However, in this regard X12.7 is no more unique than X12.6 and X12.5, which are the foundation standards for X12’s approach to EDI. However, with these few exceptions there is nothing to prevent any other organization from using CICA and X12.7, therefore nullifying any claim that they are "proprietary".

13. "Rogue" effort

The development of CICA and X12.7 is described as having been a "rogue" effort.

The customary usages of "rogue" imply being separated or vicious, like a rogue elephant, possibly dishonest or unprincipled, and perhaps even outlaw. X12.7, and the "ASC X12 Reference Model for XML Design" technical report on which it is based, were both developed in full compliance with ASC X12’s procedures. No procedural objections were raised either during their development or during PRB review for approval for publication.

Personally, I am disappointed with the fragmentation of the different XML based standards being developed by bodies such as ASC X12, UN/CEFACT, GS1, OASIS UBL, and others. That X12 decided to take a path that is perceived, correctly or incorrectly, as separate from the direction of other efforts, to me was based as much on political and social considerations as technical, and X12 was not entirely to blame. UN/CEFACT must bear part of the blame for unilaterally terminating the promising Joint Core Components work effort with X12. That was a significant missed opportunity and I suspect that some in UN/CEFACT now regret that decision.

In short, criticizing X12 for being "separate" is tantamount to criticizing it for doing anything at all. This is an invalid and inappropriately harsh criticism of X12's efforts.

Summary

Many of these criticisms around CICA and its specification in X12.7 are more criticisms of ASC X12 and how it has chosen to develop standards than they are technical criticisms of CICA as an architecture or its representation in XML. No SDO is perfect, and ASC X12 is no exception. It has made many decisions over the years, even before anyone ever thought about XML, that have been and are still being questioned. Since this article is primarily concerned with criticisms of CICA as an architecture and not on the viability of ASC X12 as an SDO, I will not address them here other that to say that even despite its flaws, at this particular time I still regard X12 as viable and relevant an SDO as UN/CEFACT and similar bodies.

Regarding the criticisms of CICA, many are based on a deficient reading and misunderstanding of X12.7. Others are accurate about what is and is not covered in X12.7 but are more based on the critic’s personal expectations about what should have been covered rather than what X12.7 actually is intended to address. Finally, others do address valid issues and these are either under discussion or have already been addressed.

I doubt if there are many who desire more than I do to see alignment and cooperation among the various SDOs developing XML specifications. However, making those a reality requires more than will. It requires commitment, time, and resources from companies, government and other organizations, and individuals participating in the various SDOs. ASC X12 has been criticized for deficiencies in its efforts in CICA, but participants in UN/CEFACT, OASIS, OAGi, and others have their own issues and must make the necessary efforts as well. At present I see very few doing what it will take. I hope that addressing some of these CICA criticisms helps illuminate one of the several paths forward toward aligment and cooperation. Time will tell whether people care enough about alignment and cooperation to make the investments that are required to follow these paths.

© Michael C. Rawlins

About  |  Services  |  Resources  |  Contact

©Rawlins EC Consulting 2007