It seems there are new systems or formats being promoted all the time that claim to be a new “Industry Standard”. Some are obvious attempts by particular software producers to try to push their own standard, skewed to their own product, as a standard for the Internet or some market segment, with the obvious intent of trying to give their own product an advantage.
Some have the same purpose times but are paraded with a more subtle approach. Only a few are genuine moves to introduce a new standard that will be truly cross-system and vendor-neutral.
One such new standard is the IFC (“Industry Foundation Classes”) developed by the IAI (“International Alliance for Interoperability”) – an organization notable for being almost as difficult to pronounce in both its full and its acronym title! The IAI is a division of the ISO (“International Standards Organization”) – the body that controls the IGES and STEP data standards.
The IFC system is a data representation standard and file format for defining architectural and constructional CAD graphic data as 3D real-world objects, mainly so that architectural CAD users can transfer design data to and fro between rival products with no compromises. It uses the 3D object-based CAD concept, which is quickly emerging as the new standard CAD rationale for the industry. Since the IFC specifications describe building object representations, it is not so clearly applicable to design using the older line-based or 2D CAD methods, although there are some software products using line-based CAD that have effectively implemented IFC data exchange.
Until fairly recently there were few CAD systems using the 3D object-based method – for example, ArchiCAD – so the applicability of IFC for inter-product exchange was limited. But now, just as the IFC development process is starting to approach completeness, more such systems are emerging, notably Nemetschek’s Allplan, Autodesk’s Architectural Desktop, and MicroStation Tri Forma. Several producers or more specialized software for the building and construction industry are also working with the IFC system.
The IAI’s IFC system comprises a set of definitions of all the objects to be encountered in the building industry, and a text based structure for storing those definitions in a data file. A plain text file is used because that is the only truly universal computer data format. Then each producer of a CAD product can store their own data in whatever compact binary file format they wish to best suit their system. In addition they provide “Save As IFC” and “Read IFC” options, which map the IFC object definitions to the CAD system’s representations of those objects. Since this involves no compromise conversions such as has been common between different CAD systems, perfect data transfer is possible between any products that have IFC save and read facilities.
As the development work on the basic IFC set for graphic representation slowly moves toward completion, there have been moves to extend its scope to supporting data associated with estimating and project management and similar non-graphic data, although the IFC system is essentially a graphic representation or object modeling system.
Meanwhile, on August 12, 1999 another standard was proposed called aecXML. The initial work and publication of this proposal was done by Bentley Systems. In the August 12 announcement, Bentley said it was “offering the initial specification for industry review and comment and establishing an independent working group to make sure aecXML becomes an industry standard with broad, vendor-neutral support in service to all segments of the global AEC community.” David Weisberg, Publisher of AEC Automation Newsletter said at the aecXML launch, “This is big, big big news. Finally! The construction industry can surely benefit from aecXML for project communications.” Within a week, over 100 software companies, research institutions, standards bodies, AEC firms and other interested parties had responded to the launch of aecXML.
Initially it was not clear whether this was going to be a rival system to the IAI’s. In fact, the aecXML system is designed for all the non-graphic data involved in the construction industries, and has a place alongside the IFC system, although some of the more recent moves to extend the IFC system to non-graphic data do seem to overlap.
Bentley developer Bhupinder Singh, who is coordinating Bentley’s ongoing participation in the aecXML Working Group explained: “aecXML is for talking about things, not modeling them. We can use it to agree what ‘door’ means, but aecXML won’t describe doors or model them.” That seems to delineate quite clearly the basic divide between aecXML and the IFC system, and also how they are mutually related.
The main idea with aecXML is to not only establish some standard ways of structuring building data but also to do it so as to enable automated processing of that data as much as practicable. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, or as spreadsheets or databases. The aecXML system provides a set of keywords and named data attributes, so that all users will employ the same naming logic and grouping, and software will be able to make use of the data without it needing to be interpreted by humans and manually re-entered in each program’s required form. This is currently often the case with for example, costing systems.
The name “aecXML” derives from AEC meaning “Architectural, Engineering and Construction”, and XML, which is a term for a type of structured text data, standing for “eXtensible Markup Language”. That in turn derived from the earlier SGML – “Structured Generalised Markup Language”, which had also given rise to its now very well known sub-set, HTML or “HyperText Markup Language” – the main data mechanism of the World Wide web.
Most readers of this article will know that HTML comprises text with control codes, called Tags, embedded within the text to “mark-up” how the text should be displayed. The tags are enclosed in angle-brackets to distinguish them from the text to be displayed or printed. The SGML system used the same scheme. As the Web grew and demand drove the provision of fancier display options, HTML evolved and diverged from the SGML standards. Now there is a move toward XML to accommodate more complex forms of data and to enable logical adaptation to types of data not yet specifically catered for. A web page can be defined in XML instead of HTML, but, most significantly, a web page created in XML can be queried as if it were a database; the results being presented in a browser vary depending on the nature of the query. Without XML, there needs to be a separate data base system and rather complex web-page-to-database sub-systems.
Since aecXML started to establish itself, the idea has already extended to other specific fields of work, and there is now a LandXML for standardising data associated with mapping, survey and civil works.
The aecXML system uses data-type tags in angle-brackets as in HTML, so that a data processing program can easily be made to search for the relevant tags and extract the required data text or numbers, confident that the correct chunks of data had been found. It should have particular usefulness in the fields of estimating, quantity surveying, and project management. Those are the areas where there appeared to be room for overlap or conflict with the IAI’s IFC work. So I was pleased to read that the two bodies were to merge. This should ensure that these two developing systems will move forward to complement each other in a very satisfactory manner.
The acting director of the aecXML Working Group is Jerry Laiserin, a well-known architect, writer and information technology consultant. He is a contributing editor at Architectural Record, chairs the American Institute of Architects Center for Advanced Technology Facility Design, and serves on the Executive Board of the International Facilities Management Association Computer Applications Council. At the aecXML announcement, Laiserin said, “In the networked economy, the more you share information, the more value you create. AecXML is the key that will unlock the value of shared information throughout the global AEC marketplace.”
The interim standard specification for aecXML is openly available on the web in PDF format. See the links below.
aecXML Working Group
IAI (Australian Chapter)
