Jonathan Cohen and Associates

Architects search the Web for product information, code and building type research, and many other things. But searching the Web is often frustrating, because Web pages written in the standard HTML language do not describe their content to search engines. A new Web language, Extensible Markup Language, or XML, will make searching for specific content much easier, with wide-ranging implications for business-to-business communication such as occurs in every building project.

While HTML describes how data should be presented, XML describes the data itself. A number of industries and scientific disciplines—medical records and newspaper publishing among them—are already using XML to exchange information between companies using previously incompatible of software. Two companies who are active trading partners could invent their own schema, or XML language, just for them, or entire industries can agree on standards. XML can be tailored to describe virtually any kind of information in a form that the recipient of the information can use in a variety of ways. XML tags can identify every attribute of products and building components, from bending strength to reflectivity. It is specifically designed to support information exchange between systems that use fundamentally different forms of data representation, as for example between CAD and scheduling applications.

For any language to function, there must be agreement on the precise meaning of terms. The success of XML to enable the open information sharing that is needed to integrate the building process hinges on finding away to standardize terminology used in the industry. At present, different players within the AEC industry use the same term in different ways. For example, a door can be, depending on context: (1) an opening in a wall; (2) an assembly consisting of a frame, a leaf, and hardware; (3) a scheduling item; (4) a cost item; (5) a product to be manufactured and delivered; or (6) a building asset to be tracked and managed. An industry-specific implementation of XML will need to be precise enough to clarify these different usages and be flexible enough to grow over time.

In 1999, a working group, since folded into IAI, began developing an XML language for the building industry, called aecXML. A parallel effort in the UK has produced PISCES, an XML language for the life cycle of real estate assets.

PISCES - an XML schema at work automating property valuation in the UK

When XML is used to write project specifications, for example, a contractor will be able to extract both quantitative and qualitative data and match it with information from manufacturers’ and subcontractors’ Web sites. A manufacturer will be able to scan a set of contract documents and match specified items with items in its own catalog, take an order, and move it into production and delivery. Once that product arrives at a job site, carrying the same XML code written by the original specifier, a construction worker using a scanner and handheld computer will enter it into the master schedule for the project. In fact, XML could be used to describe virtually all the objects, documents, services, and organizations needed to complete a project. Because data about these attributes is divorced from the program used to create it, information is no longer imprisoned by file types and software incompatibility.

Because much richer information can be described in XML than with HTML, Internet searches will be far more focused and robust than they are at present. Because XML separates data from presentation, XML documents could contain information that would be visible to some users and invisible to others. Users can filter the information themselves, extracting only the specific data needed, or create collapsing and expanding views of the data on demand. The implications for Web-based operation manuals, equipment schedules, and the like are enormous—a maintenance engineer, for example, could easily extract only the specific information needed to service a building component from a mass of data that would otherwise be overwhelmingly complex. One application of XML will allow users to access different aspects of a single database and display them in a customized way. The project file is now completely divorced from any paper representation of it; an unlimited variety of context-based views of the same information is now possible. The very notion of discrete types of standalone documents—plans, specifications, correspondence, schedules—would become obsolete.

The promise of Internet-delivered product data goes far beyond replacing paper with Web sites. Products could be classified with far richer detail than they are at present. Properties including shape, behavior, performance data, and transport requirements, along with embedded links to relevant code requirements and test results, could all be included in an electronic specification. Architects would be able to compare price and performance of various models, check available finishes, or study the energy consumption of a product when used in a particular sun exposure. Instead of serving as a static single-use document, a product specification could actually “learn,” not only during the design and construction process but over the life cycle of all buildings known to contain the product. Performance issues, maintenance, and replacement data could all be integrated into such a “living” specification.

An example of XML implemetation specifically for the building industry is Meridian Project Systems Proliance.

Back to our Home Page