THE LIMITATIONS OF ARCHITECTURAL XML-POWERED DATABASES

Transcription

1 THE LIMITATIONS OF ARCHITECTURAL XML-POWERED DATABASES Open Standards versus XML Glue JAROSLAW SZEWCZYK Bialystok University of Technology, Faculty of Architecture ul. Krakowska 9, Bialystok, POLAND Abstract. The paper deals with the limitations of architectural XMLpowered databases, focusing on flexibility of data notations. Standard commercial notations are taken under consideration, to recognize XML potential in processing open, scientific architectural data. 1. The Problem One of the most difficult problems in CAAD is a great variety of data notations. A great work is made to solve this problem: common standards for interoperability as well as vendor-specific ones were expecting to satisfy both software vendors and users. Autodesk had popularized DXF standard and in fact DWG, which then was promoted by OpenDWG Alliance. ISO has developed first IGES, then STEP, International Alliance for Interoperability has worked out IFC definitions, and also GDL language has became a well known standard for architectural notation, as a result of Graphisoft s efforts followed by GDL Alliance s and GDL Technology s activities. These were only beginnings of world-wide standardization attempts. For the last three years some hundreds of vendors started to develop different XML schemas as panacea for interoperability problems. But the use of the old structural CAD notations, new object-oriented ones and even the latest XML-based architectural representations was limited until now. The existing technologies haven t been developed definitely (like aecxml, DesignXML) or theirs appliance is not satisfying yet (BLIS-XML, adpml, RedlineXML). The basic limitation of these technologies is defining new data sets unforeseen in XML schemas, and processing complex data in flexible, open 65

2 SZEWCZYK, J. context. This implies problems with creating XML-based architectural databases. The existing, fixed data sets are too complex, difficult to deal with, they are often inconsistent and in result they are not really oriented towards architecture. Architectural notations lack the architectural meaning. 2. The Outline of Architectural Databases There were many attempts to reshape architectural data in order to get consist database for design, educational or scientific purposes. For example Gu and Xie (1998) describe a database composed of three types of libraries: specifications library, case library and generative mode library. Architectural data are in fact a special example of hybrid metadata. The problems of managing hybrid data have been well recognized. For instance Loudon (2000) summarizes the investigations on digital data repositories and digital libraries. Interesting analysis of repositories are also made by others (Kahn and Wilensky, 1995; Arms, Blanchi and Overly, 1997). The model of digital data repositories and digital libraries can be a good approximation of architectural database for scientific/educational purposes (but not for design). Arms, Blanchi and Overly (1997) recognize four main modules of digital libraries: user interfaces, repositories (a database can have many repositories of various types), a handle system used to identify resources, and an independent search system, based on query languages and keyword search capabilities. This modular approach can be acceptable for architectural databases, but we can add to this a data processor, i.e. CAD engine. In some cases, but not from user s point of view, a data processor can be perceived as a part of an interface. These four main database s elements are outlined below USER INTERFACES AND DATA PROCESSORS Integration of CAD data structure and the user interface was recognized as an important aspect of engineering systems (Anumba, 1996). Arms, Blanchi and Overly (1997) suggest necessity of dual interface for digital libraries, i.e. one interface for users (data extraction) and the second one for managers (data processing). This can make sense in CAD scientific/educational databases. Common user interface problems in CAD are recognized in detail and divided into 24 groups by Jakimowicz and Szewczyk (2001). Some interesting CAAD interface concepts follow by implementing XML-based technologies (like i-drop) in new commercial software, such as Autodesk Architectural Studio, especially if running as ASP programs in standard web browsers. Other concepts, significant for the subject matter, can be found in XML-based PDM applications, tightly integrated with 66

3 THE LIMITATIONS OF ARCHITECTURAL XML-POWERED DATABASES CAAD engines, or even in extranet CAD portals REPOSITORIES Szykman, Racz, Bochenek and Sriram (2000) describe a web-based depository system for representation, sharing, and reuse of corporate design data (emphasizing the differences between databases and data repositories). Gu and Xie (1998) discuss the implementation of the dynamic engineering component database, focusing on the data organization and access. Van Leeuwen (1999) describes notations of feature types when analyzing framework for feature-based architectural modeling. In many cases current works focus on organizing data. Arms, Blanchi and Overly (1997) recognize (1) digital materials, (2) key metadata, contained in object s definition to manage it, and (3) structural metadata that describes the types, versions, relationships and other characteristics of digital materials. There are also researchers who suggest multi-leveled architectural data organization using the XML syntax, but on the other side there are skeptics, such as Fisher, Burry and Woodbury (2000), who insist that XML specifications suffer from a conceptual deficit, and that XML was not primarily intended to provide containers for data storage but only to enable data transport between domains HANDLE SYSTEMS Handles are used to identify resources over long periods of time and to manage materials stored in repository. Identifiers concept can help with reducing data redundancy and with increasing flexibility of data structures SEARCH SYSTEMS Search systems are essential for large hybrid data repositories. If using XML-notated data structures, it is important to implement search systems of both types: query-based search engines (query languages) for extracting data records from databases with known structure, and keyword search engines for searching unstructured data. When dealing with heterogeneous, complex architectural data, search systems must be well integrated with handle systems and indexing services in order to accessing unclear metadata THE ADVANTAGES AND THE LIMITATIONS OF XML USAGE The XML usage for data notation has many advantages: XML syntax can be used to describe large hybrid data sets in relatively simple intuitive manner; self-describing data can be saved in ASCII files based on language- 67

4 SZEWCZYK, J. independent UNICODE standard, shared between different applications and platforms, and managed efficiently (van Leeuven and Jessurun, 2001b). The XML usage can add some value to user interface, for example the XML document can have many different presentation styles, which can be managed independently. But on the other hand CAD data needs conversion to any of the existing XML dialects. Fisher, Burry and Woodbury (2000) notice, that XML itself is purely syntactical with no means for semantic definitions, so that data might easily be misinterpreted, and XML do not represent well design tasks, which consist of an unpredictable number of elements with an unpredictable number of attributes. These researchers write: Interoperable standards require the opposite: experiences made in well-known problem spaces upon which a finite number of data elements and attributes can be collected and become specified as a problem-oriented communications protocol. Besides, the XML-based CAD data notations suffer from rough semantics. Semantics of XML-notated architectural data are in many cases oriented towards needs of cost-working applications. The overview of the existing notations is presented below. 3. The Existing Notations of Architectural Data 3.1. STRUCTURAL EXPRESS BASED DEFINITIONS: STEP AND STEPML STEP is not an architectural standard, but its popularity in CAD world and its features make him a potentially acceptable basis for further development for AEC. STEP is organized as a series of parts, published separately and defined using a formal specification language, EXPRESS. These parts are grouped as follows: description methods, integrated resources, application protocols, abstract test suites, implementation methods, and conformance testing. STEP uses application protocols (APs) to specify the data representation for different applications. Only a few of APs can be potentially applicable in AEC; these are the following: AP230 (Structure), AP232 (PDM), AP201 and AP202 (Draughting), AP225 (Spatial Arrangements), AP228 (HVAC), AP212 (Electrotechnical). It is expected that in the future several hundred of new APs may support many industrial applications (and AEC applications among them). On the present stage of development STEP can t really compete with other data notations in AEC application fields, especially in architecture. None of popular architectural applications uses STEP (except of general CAD drafters, such as MicroStation, which can export and import data to/from a few APs). But there were several attempts to construct STEP-based models of architectural 68

5 THE LIMITATIONS OF ARCHITECTURAL XML-POWERED DATABASES data, for example Popova (1998), and Watson and Wambugu (2000). StepML is a library of XML DTD's (Data Type Definitions) that are based on the content models from the STEP standard. The ISO EXPRESS data modeling language PDM Schema version 1.2 (upon which the DTDs are based) consists of over 2100 code lines, and provides the STEP semantics to be used within the web. The stepml is not dedicated for architects and it has all the limitations specific for STEP notation. From the architect point of view it can be used for exchanging general CAD data, so its potential application in architecture is rather limited, unless the proper STEP Application Protocols and stepml schemas will be developed OBJECT IFC-BASED NOTATIONS: IFC, IFCXML AND BLIS-XML The IFC classes were developed for a wide range of applications, such as: architecture, building services, structural engineering, project management, cost estimating and planning, maintenance, and space management. That is why IFC defines a great variety of class definitions. Relatively small part of it is dedicated strictly to architects: in effect IFC definitions lack consistency in defining architectural database structures. Besides, their structure is rather software-oriented : the IFC specifications are defined in the EXPRESS language, and secondly, the IFC 2.x structure is very atomized (consists of the four layers and many classes). IFC seems to serve well commercial architectural applications, but it hasn t been implemented in many CAD programs yet. The existing implementations are: Architectural Desktop 2.0 and higher (Autodesk), ArchiCAD 6.5 and higher (Graphisoft), ALLPLAN/ALLPLOT FT v.16 (Nemetschek), Visio Technical Edition (Microsoft), ARCHITREND 21 (Fukui Computer Inc.) and some cost estimating software. The ifcxml defines some hundreds of IFC elements in XML syntax. 70 percent of elements definitions do not describe spatial information, and 50 percent include information used rather by cost estimators, work schedulling programs and other non-architectural applications. The ifcxml syntax consists 2269 code lines, so this can be regarded as rather big and softwarespecific notation not only for architects. BLIS (Building Lifecycle Interoperable Software) is a small group of members of IAI developing BLIS-XML an EXPRESS Schema notation based on XDR (XML data reduced), in order to provide efficient IFC import/export using XML syntax, to enable the use of IFC model data in applications that can read/write data in XML format only (for example standard web browsers). Its reduced, but effective syntax enables BLIS- XML to play an important role in present software development, and potentially enables its to be implemented in architectural scientific databases. These are not the only attempts to translate IFC into XML 69

6 SZEWCZYK, J. language. An aecxml version of the IFC has also been generated XML-BASED NOTATIONS FOR AEC The aecxml is one of the most popular and the biggest XML dialect for AEC industry, which is being developed since 1999 by IAI and includes some stand-alone standards (such as LandXML). Now about 700 organizations, companies and individuals are involved in aecxml improvement. Its syntax is worked out by 7 working groups: Catalogs Working Group; Design/Specification/Scheduling/Costing Working Group; Facility Management Operations & Maintenance Working Group; Procurement Working Group; Project Management Working Group; Project News Working Group and Plant Working Group. This shows that developers of aecxml pay special attention to data interoperability between various application fields through product lifecycle; they do not focus on architecture itself nor they create architectural notations for stand-alone architectural databases. Besides, educational, experimental and scientific usages of aecxml are on the margins of developers interests. The GreenBuildingXML (gbxml) schema, published in summer 2000 by GeoPraxis, describes buildings construction for the purposes of energy and resource analysis. It allows data interoperability between CAD programs and building analysis applications (such as DOE-2.2). The schema describes 261 elements, 85 simple data types and contains 4091 code lines. On the opposite, the DesignXML is a relatively small and simple set of XML definitions describing geometry in 3D space (it has 76 code lines only). It is not sophistically oriented towards architecture, but it is rather geometry-oriented. DesignXML seems to be interesting due to its simplicity and potentially can be a base for more advanced architectural notations. It can also work with existing on-request XML formats such as SVG. DesignXML syntax allows for association XML data with undefined in schema or even external pieces of information due to elements called Link. The Link element is used to associate elements in the common DesignXML channels with other bodies of information, including records in an external database. Interpretation of links is the responsibility of the applications implementing them. The BcXML is the building-construction XML dialect developed by the European organization econstruct (Electronic Business in the Building and Construction Industry) for supporting electronic business in AEC domain, and for integration of engineering AEC applications. The adpml is an Autodesk solution for developing and distributing electronic design catalogs that supports hierarchical part classification and allows self-publishing to a central searchable directory. Its potential for architectural databases cannot be underestimated. 70

7 THE LIMITATIONS OF ARCHITECTURAL XML-POWERED DATABASES The RedlineXML enables to exchange digital design revision markups relative to design documents. It has been incorporated into some existing CAD/PDM software, for example Autodesk's Volo View. The LandXML schema facilitates the exchange of Land Planning, Civil Engineering and Land Survey data. LandXML has been embedded in aecxml. There are worked out the technologies for Converting LandXML coordinate geometry to GML (Geography Markup Language) in order to being used by GIS databases. Now LandXML Design Data Model consists of 121 elements and its code contains 2878 code lines. The i-drop is an Autodesk XML-based technology which enables to create web content with the ability to drag and drop design content from a web page directly into design. I-drop works with the software, which have installed i-drop ActiveX controls (idrop.ocx). The i-drop ActiveX control is data-ignorant, because it's only responsible for transferring bytes and it doesn't interpret the data. Therefore i-drop can t be regarded as a stand-alone technology for data description in databases. The SVG is an XML grammar for describing two-dimensional graphics. It includes elements for vector graphic shapes, raster images, animation, and text. There are successful attempts for applying SVG notation for describing GIS and GIS-relative information, including maps, site plans etc 4. Conclusions 1) The existing XML-based technologies (enabling application interoperability and management of heterogeneous information) are generally not optimized for architectural data storage. 2) Merging XML notation and CAD software-specific data notations (like i- drop technology merging with adpml cataloguing capabilities) seems to be the best way to handle large amounts of architectural data, but it is not enough for building architectural databases for research purposes. 3) Defining standards for open architectural data sets is required to construct such databases. 4) Detailed investigations of XML potential in architectural notation are needed to work out software technologies and methods for scientific, semantic-insensitively communication and intuitive CAD data handling. 5) We can agree with the statement made by Fisher, Burry and Woodbury (2000) that XML is easy to learn and applications are easily implemented but when it comes to mission critical large-scale projects, the investment in DBMS-handled storage and transaction appears to be the better choice. 71

8 SZEWCZYK, J. Acknowledgements This work is supported by rector s grant at Bialystok University of Technology (Faculty of Architecture), Grant No. W/WA/4/00, funded by Polish Research Council References Anumba, C. J.: 1996, Functional Integration in CAD Systems, Advances in Engineering Software, 25, Arms, W.Y., Blanchi, C. and Overly, E.A.: 1997, An architecture for information in digital libraries, D-Lib Magazine, 2; Fisher, T., Burry, M. and Woodbury, R.: 2000, Object-Oriented Modelling Using XML in Computer-Aided Architectural and Educational CAD: The Problem of Interoperability exemplified in two Case Studies, in CAADRIA 2000: Proceedings of The Fifth Conference on Computer Aided Architectural Design Research in Asia, Singapore, pp Gu J.and Xie G.: 1998, Dynamic Database Management in Computer Aided Residential District Design System, in: CAADRIA'98: Proceedings of The Third Conference on Computer Aided Architectural Design Research in Asia, (eds.) T. Sasada, S. Yamaguchi, M. Morozumi, A. Kaga, and R. Homma, Osaka University, Osaka, pp Houlding S.W.: 2001, XML - an opportunity for <meaningful> data standards in the geosciences, Computers & Geosciences, 27, Jakimowicz, A. and Szewczyk, J.: 2001, Multi User Interface Problems in Current CAD Systems, in M. Stellingwerff and J. Verbeke (eds.), ACCOLADE Architecture Collaboration Design, DUP Science, pp Kahn, R. and Wilensky, R.: 1995, A framework for distributed digital object services, in Loudon, T.V.: 2000, Geoscience after IT. Adjusting the emerging information system to new Technology, in Computers & Geosciences, 26, A109-A121. Popova, M.: 1998, Model of Design Parts and its Use to The Design Team, in CAADRIA'98: Proceedings of The Third Conference on Computer Aided Architectural Design Research in Asia, (eds.) T. Sasada, S. Yamaguchi, M. Morozumi, A. Kaga and R. Homma, Osaka, Japan, pp van Leeuven J.P. and Jessurun A.J.: 2001a, XML for Flexibility and Extensibility of Design Information Models, in CAADRIA 01: Proceedings of the Sixth Conference on Computer Aided Architectural Design Research in Asia, Sydney, pp van Leeuven J.P. and Jessurun A. J.: 2001b, Added Value of XML in CAD, in Proceedings of AVOCAAD 2001, Brussels. van Leeuwen, J.P.: 1999, Modelling Architectural Design Information by Features, PhD thesis, Eindhoven University of Technology, at Watson A. and Wambugu W.: 2000, A Product Model Based Architecture for Engineering Applications Software, at Szykman, S., Racz, J., Bochenek, C. and Sriram, R.D.: 2000, A Web-based System for Design Artifact Modeling, in Design Studies, 21(2), Elsevier Science Ltd., pp