aecXML a Framework for Electronic Communications for
the AEC Industries
By Keith Bentley
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.
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 with a few rules for defining new data types. XML has gained considerable attention in its brief existence 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.
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.
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.
However, none of these expectations are likely to be realized without some new industry wide agreement on the vocabularies used to exchange AEC technical information.
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 matrix of participants and information transactions is quite large,
particularly when plotted over the project life cycle. 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.
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.
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.
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.
Those goals translate to a few principles to keep in mind when creating
the aecXML specification:
It must be easy to implement with existing application software and
databases. Use existing keywords, properties and classification approaches
where applicable. A 90% solution today is better than a 99% solution next year. 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."
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 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:
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. 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. 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.
For more information on aecXML, including an expanded version of this article and the working draft of the initial aecXML specification, as well as the aecXML Working Group, go to http://www.aecxml.org on the Internet.
About the author: Keith Bentley is Chief Executive Officer of Bentley Systems, Inc., a large international a/e/c software developer.
The CSRF newsletter is published for SPECTEXT® subscribers and others involved in design and construction. To obtain your copy of Creating a Common Language®, please contact the CSRF Support Center by telephone at 1-877- SPECTXT or 410-838-7561 or you may e-mail us at supportcenter@csrf.org
Home | About | Board | Research | WebFormat™ | Contact Us | Newsletters
Publications | News Releases | Related Sites | Search