*5.1.2 Event driven*

A controller only receives a message when a change of state occurs, so it is truly 'event driven' and it interprets each received event in the context of the source of the event message and the current state of other known information. The source of the message needs to know nothing about the functionality that lies behind the interface, allowing great flexibility for the controller designers to evolve and improve their design. This 'encapsulation' is a fundamental characteristic of the object orientated programming paradigm [35].

#### **5.2 Publication of a standard schema**

However, it was not until the introduction of functionality into Internet web pages, supported by tools and technologies based on XML, that it became practicable to publish a formal statement of the full set of terms and relationships necessary to define lift operation. The format of this publication is a single XML schema file written in XML Schema Definition (XSD) language that is at once readable by humans and a wide range of computer operating environments. It contains specifications of:

*Standard Elevator Information Schema: Its Origins, Features and Example Applications DOI: http://dx.doi.org/10.5772/intechopen.92552*


• aggregation relationships with optionality and multiplicity restriction rules, and every definition can be elaborated with textual documentation for the benefit of human readers.

So it was that in 2003 the knowledge from the earlier work was translated into an XSD – the Standard Elevator Information Schema – by Beebe and made publicly available [32] under the Collective Commons licence. It is hoped that through this mode of publication, discussion of the relative merits of any alternative schemas, should they be developed, would be limited to technical concerns thereby avoiding commercial and proprietorial considerations. The reference works of the day [36, 37] were analysed to identify significant nouns and their definitions that might form the atomic elements of the schema to ensure a wide-reaching scope. At the same time terms that were not directly relevant to lift operation were carefully excluded in order to avoid duplication or conflicts with schemas for other domains, currently available or potentially in the future. Based on the foundation elements and a more general survey of research across the field of lift traffic analysis, monitoring and simulation, further useful complex elements were identified and added to the schema e.g. demand profile, travel plan, door cycle, etc.

Two possible interaction modes were envisaged for SEIS at its inception (though a further mode was introduced with the application of REST transactions and more may be discovered as experience is gained):


This was the starting point for the root element types in the schema:<sup>2</sup>
