A Framework for Electronic
Communications for the AEC Industries
Overview
aecXML™ is a framework for using the eXtensible Markup Language (XML) standard for electronic communications in the architectural, engineering and construction industries. It includes an XML schema to describe information specific to the information exchanges between participants involved in designing, constructing and operating buildings, plants, infrastructure and facilities. The various software applications used by these participants can transfer messages formatted according to the aecXML schema to coordinate and synchronize related project information. In addition, a standard aecXML specification will facilitate e-commerce between suppliers and purchasers of equipment, materials, supplies, parts and services based on that same technical information.
Bentley Systems, Incorporated has created a preliminary specification for the aecXML framework and now seeks to join efforts with other parties interested in defining and implementing the aecXML schema.
The aecXML framework is intended to embrace the other emerging XML-based standards for electronic business-to-business information exchange such as the Microsoft BizTalk framework. It is anticipated that the aecXML framework will need to track other such initiatives and incorporate other standards as they become endorsed and accepted.
Introduction
There can be little doubt that the Internet has radically changed the way we work. Virtually every phase of the business world has been affected in one way or another by new approaches now made possible by the Internet.
However, in light of its revolutionary impact, the technology behind the Internet revolution is hardly remarkable. In fact, a strong case can be made that the most important technological change that enabled the Internet’s rapid acceptance is HyperText Markup Language (HTML). HTML is a simple, text-based protocol for describing the content of “pages” and links between them. It contains special keywords, or tags, that are not displayed on the page, but are used to define the way other text and images are displayed. The syntax of HTML is very simple, particularly in comparison to complex programming languages. In all of the HTML specification, there are fewer than 100 tag definitions, and the majority of those tags are rarely used. However, with those few tags (and of course some clever techniques along the way) people have created Web pages that contain information of every imaginable type.
This demonstrates an obvious principle in information technology: the impact of a technology depends more upon its acceptance than upon its underlying technological strengths. The fact that a few simple concepts can be used to such great advantage on such diverse problems is the great appeal of HTML.
XML is a way to apply the same principles that make HTML attractive for document presentation for the problem of data interchange. Basically, XML uses the same simple syntax as HTML (in fact, HTML can loosely be described as a dialect of XML) with a few rules for defining new data types. XML has gained considerable attention in its brief existence (version 1.0 was released as a proposed recommendation by the W3C in December 1997) and many segments of the computing industry now consider XML as “the standard” for all sorts of problems.
The greatest appeal of XML is its potential role as a universally accepted format for exchanging information. There is near unanimity across the entire spectrum of software vendors that XML will become “the next HTML”. The degree of technical unity of direction is cause for great optimism. The AEC industries, particularly, can benefit from a unifying strategy for data interchange. Not only are current data exchange and reuse practices inefficient, but also with hundreds of
thousands of transactions worldwide and annual expenditures in the trillions of dollars in the AEC marketplace, it is easy to imagine significant savings in streamlining the processes.
Expectations for AEC beyond Y2K
It is hardly bold to suggest that a high-bandwidth Internet connection soon will be as essential as a telephone to running virtually any business. A company’s home page becomes its worldwide storefront and increasingly customers, clients, partners, suppliers and contractors will expect to find each other and do business over the Web. The communications infrastructure to support these communications is largely in place, and the advances in wireless, fiber optic, satellite and software technology promise to fill in any existing gaps in short order.
AEC project participants should soon expect:
• Project information to be entered once and reused where necessary, even across organizational boundaries. It is common today for the same information to be re-entered many times by many people, simply because the information is exchanged only on paper or is stored in different formats and used by different software applications . This is particularly true as projects pass from phase to phase and as new organizations become involved in the project.
• Most present-day paper-based reports, specifications and product catalogs to be replaced by electronic equivalents. Searches for product information, specifications, pricing and
availability will be done over the Internet and in real time.
• Applicable regulatory rules, requirements and guidelines to be online and searchable in a meaningful form (as opposed to plain text searches). Further, the project submission, review and approval process will be automated much like the current U.S. electronic tax filing procedures.
• Project design and construction information to contain sufficiently rich operating, maintenance and safety information that it will truly become the “operator’s manual” for the life cycle of the building or facility. Owner/operators should gain sufficient value in such information that they will fund any extra costs for its creation.
However, none of these expectations are likely to be realized without some new industrywide agreement on the vocabularies used to exchange AEC technical information.
AEC Industry Dynamics
AEC projects can be very complex undertakings. From an information technology (IT)
perspective, they are particularly challenging. Not only are data sets large, but they also typically involve many types of somewhat unstructured, interrelated data. The data is created and used by
many types of users and software applications. For example, at any time in a project cycle, any combination of the following participants may require access to query or modify the project data set for various purposes:
- The owner/operator of the subject facility
- Architects, designers, engineers, project managers - Contractors, estimators, consultants
- Suppliers, product manufacturers - Government regulatory agencies
The matrix of participants and information transactions is quite large, particularly when plotted over the project life cycle. Many of these participants are small to medium-sized companies, and are only involved in small roles in the project (although these smaller companies tend to work on many projects at the same time). Given the diversity of the participants, and the magnitude of the data, it is not surprising to find a wide variety of software systems and users with varied degrees of computer expertise on the same project.
As in most industries, the practices, procedures and processes used by the worldwide AEC community have evolved over the past two decades from “pure paper” to what many refer to today as “computer automated paper.” This evolution has been gradual, the result of many small, disjoint, incremental steps rather than any one “big bang” change. As a result, little attention has been paid to an overall strategy for information integration. This is natural, since if anyone had ever attempted to plot a cohesive “master plan” for the industry, its magnitude would have surely guaranteed that it would never have been adopted.
Integration?
As the software technology for AEC projects has evolved, the need for data integration among participants performing different functions and using different software applications has been apparent. Several approaches to information exchange have been attempted:
• Document file transfer. Any two software programs that need to exchange data agree on a file format for a given document type and each reads, and possibly writes, data in that format. Frequently the file format is a “neutral” format defined by an external, usually organization independent of the software vendors. This approach presupposes that each application can reliably read and write all of its internal information into the neutral format, and that the neutral format itself does not change very often. Alternatively, one application can be hard coded to read and write the native format of the other. This approach generally only works well for two closely matched application programs, but is not suited for sending just a subset of a document. (This is a problem inherent in all file-based systems.) It is also subject to “lossy” transmissions, owing to the inherent mismatches between file formats of different applications. In general, document transfer cannot be considered a viable, universal, approach to integration.
• APIs (application programming interfaces). Publishing programming interfaces is an attempt to circumvent the inherent limitations of document file transfer. With this approach, rather than attempting to reformat data into a neutral file, one application makes function calls into the other program. This can greatly increase the fidelity of data interchange, since each program deals with the data in its native format. However, it obviously requires both applications to be installed, active, and available either on the same computer or on a network and that they have some knowledge of the protocols defined by each other. In addition, this “tight coupling” of one
application to another tends to be specific to particular versions of programs and is therefore very fragile.
• Shared databases. Another approach to data sharing is to rewrite the applications so that they all store information in a common, predefined database. While this approach can solve some of the above limitations, it can involve substantial reworking of existing programs, almost always with a performance penalty. More importantly, experience has shown that the common storage
approach is too inflexible to accommodate the disparate requirements of many applications running simultaneously. In practice, creating a super-database for all applications makes the database schema so complicated that applications are too difficult to create. Also, changes to the schema are impractical because they require massive, lock-step changes to so many
applications.
• Paper, phone, E-mail, faxes. Given the limitations above, the most reliable means for transferring information between applications and people is to print reports and reenter data manually. While grossly inefficient and subject to human errors, this approach is the most common approach today.
Background on XML
XML is a standard for defining the way information is interpreted when it is transferred from one computer to another. However, while agreeing on a standard like XML is a necessary step for integrating software and data from disparate sources, it is only one layer of the problem. To understand the role of XML for computer communications, we can draw an analogy to written human-to-human communications.
For two people to communication in written form, they need to both agree on: an alphabet (the symbols that represent letters)
a grammar (rules for sentence and paragraph structure, etc.) a language (e.g. French, English, German, Spanish, etc.)
a structure (left-to-right, top-to-bottom, opening and closing format, etc.) a vocabulary (the terms for common concepts, spelling, etc.)
XML itself (and the networking/communications layers below it) roughly translates to the layers up to language, above. The XML standard has rules for how to define terms, how to parse (interpret) the contents of a document and how to create valid documents. Using the XML standard
eliminates many ambiguities about how to format data in an understandable form. There are many good reference papers on the general subject of XML that give a more thorough presentation on its origins and goals. Some starting points are:
XML: Structuring Data for the Web: An Introduction - Ken Sall XML in an Instant - Charles F. Goldfarb
A Technical Introduction to XML - Norman Walsh Extensible Markup Language (XML) - W3C
Many organizations have recently been formed to use the XML standard for various business functions. Some relevant reference material can be found at:
XML.org (OASIS) BizTalk (Microsoft) RosettaNet, CommerceNet XML/EDI Group OAG W3C
Microsoft’s BizTalk
Microsoft’s BizTalk framework addresses the next layer above XML. BizTalk defines an XML-based approach for sending messages between two computers, particularly computers at different companies. The BizTalk schema defines the “envelope” for the messages, including routing, delivery and return address specifications. In this sense, BizTalk adds the outer structure to a message.
In addition, Microsoft’s BizTalk initiative includes an on-linelibrary for the vocabulary and grammar layers. The library is a well-known and universally accessible node for locating XML schemas to interpret the contents of the business messages. Microsoft will also create server-level products to process and distribute BizTalk-formatted messages. For a more complete overview, see Microsoft’s white paper on the BizTalk philosophy.
Introducing aecXML
The aecXML schema is a set of XML elements that specify the terminology, grammar and layout of business messages that contain AEC-specific content. These kinds of messages are
examples:
• An HVAC manufacturer queries the design documents to get a list of air-handling units and their design parameters. He can then associate them with specific catalog items from his product line that satisfy the design specifications.
• A contractor searches for the availability of roof shingles equivalent to a brand-name, 25-year warranty variety recommended in the architect’s design specifications.
• A contractor extracts quantities from an estimating tool and dispatches procurement requests to suppliers over the Internet.
• An employee time-keeping system (e.g. Simplex punch-clock type tracking) exchanges information with a scheduling application that keeps track of actual hours worked per task on a project.
• A PDA device at a construction site exchanges information such as an item being added to a punch list with an order-processing system or a scheduling system.
These are the types of information exchanges that transpire daily on virtually every AEC project. The aecXML schema provides the framework for formatting these exchanges in meaningful ways, without having to code each one individually.
On the other hand, the concept of “information exchange” evokes some connotations that are not within the scope of aecXML. For example, aecXML is not intended to be:
• A file format. Rather, aecXML is an XML schema that defines elements and attributes that can be used to communicate AEC-specific information between software programs. It is not expected that application programs will use the aecXML specification as their native formats for storing application-specific values. On the other hand, one can envision a utility within a software program to “Save as aecXML,” which would attempt to write out all known facts about a data set in aecXML terminology.
• A complicated taxonomy of the AEC world. One of the fundamental design goals of aecXML is to avoid undertaking the nearly impossible task of exhaustively classifying data. Of course, some categorization is necessary. However, it is envisaged that aecXML element
specifications will be broad and possibly fuzzy. (That is, as with most languages, there may be several ways of describing the same thing.)
• A “complete” AEC modeling schema. It is not the intent of aecXML to be a “super” data format to encompass all of the data types used in AEC-related software. For example, architectural modeling programs typically store information in a hierarchical fashion organized by building discipline. Within each discipline there are often intricate data structures for representing physical properties, proximity and connectivity, space enclosure, presentation properties, etc. The problem of creating data types and schemas to accurately reflect all of
that information for the purpose of transferring a complete model from one system to another has been addressed in other standards (for example, the IFC specifications created by the International Alliance for Interoperability and the various STEP APs) and is not within the scope of aecXML. (While one could debate the merits of using XML as a data-description language as opposed to using Express (the language used by IFC and STEP) for creating a modeling schema, that issue is moot for aecXML.) It may be helpful to think of aecXML as a schema for reports and forms and IFC/STEP as schemas for “live” models.
• A closed schema. It is possible in XML to specify that a schema is closed, so that no
unknown element types can be present in a validated document. However, since the scope of aecXML will undoubtedly grow over time (particularly given the high priority of publishing a working V1.0 specification as soon as possible), it is certain that the specification will need to be revised and expanded over time. It must, therefore, be possible for a program written for an earlier version of the specification to work with a later one.
• Vendor-specific. Nothing in the specification should be specific to a particular software program or vendor.
aecXML Schema Domains
This information can be resources such as projects, documents, materials, parts, organizations and professionals, or activities such as proposals, design, estimating, scheduling, construction and operations. The following types of AEC information are within the scope of aecXML. This is meant to be a representative rather than an exhaustive list.
• Documents: RFP, RFQ, RFI, drawings, specifications, ASI, addenda, bulletins, change orders, contracts, building codes, purchase orders
• Building components: items from a catalog, custom manufactured items, assemblies, materials
• Projects: design, construction, decommissioning, operations & maintenance, facility management
• Professional services and resources: engineers, architects, contractors, suppliers, specialties • Organizations: standards bodies, government agencies
• Software: CAD, estimating, project management, scheduling, document management The following software modules are likely to be generators and processors of aecXML formatted messages:
• Document/project management, CAD, estimating, project management, scheduling, resource planning, inventory management, procurement, maintenance repair and operations.
aecXML Principles
The design goals of aecXML must be aligned with those of XML in general. It is useful to reiterate them from the XML specification. See http://www.w3.org/xml for more details.
1. XML shall be straightforwardly usable over the Internet. 2. XML shall support a wide variety of applications.
3. XML shall be compatible with SGML.
4. It shall be easy to write programs which process XML documents.
5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero. 6. XML documents should be human-legible and reasonably clear.
7. The XML design should be prepared quickly. 8. The design of XML should be formal and concise. 9. XML documents shall be easy to create.
10. Terseness in XML markup is of minimal importance.
Those goals translate to a few principles to keep in mind when creating the aecXML specification: 1) It must be easy to implement with existing application software and databases.
2) Use existing keywords, properties and classification approaches where applicable. 3) A 90% solution today is better than a 99% solution next year.
4) The more detailed the schema, the harder it will be to write programs to create and read messages. Most aecXML (sub) schemas should “fit on the back of an envelope.”
The aecXML Working Group
A useful and widely adopted XML schema can greatly benefit the AEC communities at large and is virtually a prerequisite to realizing the vision of an electronically connected business
environment for AEC projects. For that reason, Bentley has formed of the aecXML Working Group. The purpose of the Working Group is to give all interested parties a forum to contribute either implementations or suggestions for aecXML schema subsections.
As with many industry initiatives, the aecXML Working Group will be comprised of constituents from industry, government, research communities and end users. It should be clear that each participant will have self-centered motives for participating and that cooperation among business competitors is required. However, the usual competitive concerns about contributing proprietary intellectual property should be moot, since:
1) The very essence of XML, and aecXML, is that it is a mechanism for communications among systems. A proprietary XML schema makes about as much sense as a proprietary fax format.
2) Any XML-based work is, by definition, distributed at the source level. In other words, there is no way for anyone to do anything in XML that is not freely visible to the rest of the world. 3) Everyone is on the same footing. The only way one company can be put at a disadvantage
with respect to its competitors is by not participating.
Of course, everyone involved will be well aware that helping themselves means helping their competitors. Participants will certainly compete on their implementations of the schema, but not on schema itself.
A primary goal of the aecXML Working Group should be to publish an initial schema quickly, to enable existing applications to communicate effectively using the schema. Obviously, though, creating a workable first version of the schema is only the beginning of the work required to create a permanent “standard.” After a working version of aecXML has been created, the aecXML Working Group should turn over the schema to organized standards bodies. Another important responsibility of the aecXML Working Group will be to ensure that the schema is compatible and synchronized with other XML-based initiatives.
