||Standardization is generally considered to be the ultimate solution to the problem of data exchange among collaborative partners. Yet, in non-digital exchanges, standardization has never been much of an issue and project partners exchange information without any need for global standardization. Instead, whenever possible, they rely solely on their own knowledge in order to interpret exchanged data and, otherwise, query the author(s) or colleagues for an explanation. In digital exchanges, one cannot simply rely on such knowledge to be present in the computer or application. Furthermore, it goes against the very essence of digitalization to expect the user to assist the application in interpreting this data, especially considering that even common sense eludes software. As a result, a standardization approach has been at the core of most research efforts in order to resolve this data exchange problem. The assumption is simple: if everyone adopts the same concepts, vocabulary, and language, any data expressed within this language will be accessible to everyone.However, the real question that should be considered is whether standardization will improve the design process through effective data exchange or, instead, hinder the design process by imposing a specific language for designers to express their ideas and conceptualizations in. Ultimately, the designer will be restricted by her ability to translate her design from whatever representation she chose to develop her design within to the standard representation necessary to exchange her design with others in the design and building process. In most cases, this will mean that a designer is limited to using those representations or applications for which translational facilities are provided for and none other. Recent history has shown us that the AEC CAD software industry is everything but a frontrunner when it comes to new developments. Instead, many progressive architects are and have been forced to adopt CAD software from other design disciplines in order to express and represent their architectural designs, such as CATIA, first developed for the aerospace industry, or Maya, developed for the animation and movie industry.To the extreme, it could be argued, with the danger of antagonizing those that are heading the strive for standardization, that this process of standardization is little more than a struggle for self-preservation. It is a fact that were the AEC industry to accept a single standard, the main CAD software developers could afford as before to lag behind in their inclusion of new features or techniques, without having to fear being left at the wayside of evolutions that find their origin in other disciplines. A standard to which almost everyone would adhere to would offer them the necessary time to respond to such outside influences: CAD developers active within other disciplines may not be tempted to adhere to a standard that is outside of their action radius, unless after this radius is enlarged by designers from within the AEC industry exploring the effectiveness of these software applications for their own purposes. Instead, such designers may be forced, as a result of project partners requiring an adherence to this standard, to invest themselves in the development of a translational facility to convert the resulting data from this application into the standard’s representation or, instead, wait patiently until such a facility may become available. Even then, such a translational facility will necessary reflect on the current status of the standard, which may not be fully compatible to the concepts or techniques underlying the outside tool or application.In this paper, we discuss the effectiveness of a conceptual standardization in attempting to solve the problem of data exchange within the design process, as well as the role a common syntax may play in easing data exchange while offering designers full flexibility in choosing how to express their architectural designs.