Balisage Paper: Leveraging XML Technology for Web Applications

Introduction

As eBooks evolve into interactive applications, our vision at Electronic Publishing Group (EPT) is to empower authors to write and deploy not only documents and eBooks but whole Web applications using widely available tools without system lock-in. Our work brings ideas of end-user development [F88] [FGSM04 ] to the area of Web applications.

XML technology is our technology of choice. Historically, the nature of the entities that are encoded with XML and related standards (XML Namespaces, XLink, XML Schema, RDF, Docbook, MathML, ePUB, XML syntaxes of HTML including HTML5) has evolved over time. Originally, XML encoding was applied to textual documents to support single-source, cross-media publishing. Then textual documents expanded their scope, to act as databases that can be semantically processed, and data collections were represented as (collections of) documents, to be queried or data mined. Finally, we also have snippets of data encoded with XML technology, to configure applications or to exchange messages between systems

Together with the nature of the entities to be encoded in XML and related languages, further XML technologies evolved that support these entities and their use cases: CSS, XSL with XSLT and XSL-FO, XQuery, XForms, XProc.

We intend to leverage XML technology for Web applications, looking for a methodology that lets domain experts be involved into the software development process from start to finish, even empowers them to do their own software development. We envision XML technology as open, accessible, well supported technology to be leveraged for Web applications: Information is represented and manipulated with XML technology. Data and programs are deployed on a Web server, stored in an XML database, run by XML processors (XSLT, XQuery, XProc) and accessed from XML-aware Web clients (XForms) via the HTTP protocol.

The required XML technology, such as XML processors and systems to support the various XML languages, is in place and accessible to end users. The XRX architecture provides a point of reference, how to make use of standard Web servers, Web browsers and the HTTP protocol as the plattform on which to run components of XML-based Web applications without system locck-in.

It has been argued by Baumann [B09], among others, that XML technology is implementation technology. Hence, the missing pieces, as far as we can see, are methodology, reference architectures, proven practices, case studies. That is the topic of this paper.

By way of methodology, we draw on the principles of Domain-Driven Design [E04] and Domain-Specific Languages  [F11] to empower domain experts to develop Web applications. For requirement specification and design, we adapt Abstract State Machines (ASMs) [BS03] that are refined into XML code.

We illustrate our methodology with a case study, a calendar system that we call CalendarX. Robles Hahn [RH11] designed and implemented a calendar system with XML technology using principles of Domain-Driven Design and employing Domain-Specific Languages. In this paper, we propose an extended methodology that is based on Abstract State Machines (ASMs): We formally describe requirement specification and design by a so-called ASM ground model. We envision use the ASM concept of refinement to derive an implementation in terms of XML technology.

This paper is organized into six further sections. First, we briefly discuss the application CalendarX with which we demonstrate our methodology. Then we introduce the main building blocks of our methodology, namely Domain-Driven Design, Abstract State Machines and XML technology. Finally, we discuss the CalendarX domain model, its formal specification as an ASM ground model and the CalendarX implementation. We finish with conclusions and discussion of further work.

CalendarX: Motivation and Description

We illustrate our approach with a small case study or feasibility study, the calendar system CalendarX. We demonstrate how to leverage XML technology for Web applications while working towards a methodology that lets domain experts be involved into the software development process from start to finish, even empowers them to do their own software development.

One may well question our choice of domain, arguing that anybody is a domain expert in calendars. That is precisely our reason for choosing this domain: Since this study started out as students' work in a lab course and a thesis, there were no independent, external domain experts. Students and supervisors had to be able to fill in the roles of domain experts and software developers. We feel that we can demonstrate the value of Domain-Driven Design nevertheless.

Furthermore, we have found from personal experience that migrating from one calendar system to another is troublesome when access to the calendar data is mitigated by software. Hence, we have found it worth our while to design and implement a calendar system that exposes its data in XML format, applying lessons learnt in the field of document processing.

As to the specific data model, the first author has always found the limitations of existing calendar systems irritating. Hence, we have taken the chance to add a few special requirements for CalendarX [RH11]. Foremost, we require CalendarX to support a rich domain model, going beyond state-of-the-art calendar systems such as Microsoft Outlook or Google Calendar and calendar languages such as iCalendar [D09] and xCal [DDL09].

Rich event model CalendarX is capable of expressing a relationship between events that do not follow a single repetition pattern. For example, an event that takes place on a Monday from 10 to 11 am and on a Wednesday from 2 to 4 pm can be represented as a single event, that holds information common to both instances, such as event description, category and location.

Rich recurrence pattern model CalendarX supports the usual recurrence patterns, but also combinations of patterns, including exception patterns. For example, we can specify that an event recurs every first Monday and every third Tuesday of the month, but not during school holidays.

To summarize, we consider CalendarX a good case study and we have taken the chance to design and implement a calendar system with extended functionality that we personally wish to use.

Methodology and Technology

The CalendarX Domain Model

Modeling the calendar data

We start modeling CalendarX with concepts in the calendar domain that need to be represented as data in the system, and their relations.

Our first stab at a conceptual model is a UML class diagram that captures calendar concepts, as pictured in Figure 1.

Figure 1: Modeling calendar concepts

CalendarX has a top-level concept, CalendarX. A CalendarX object contains collections of Calendar, User, Pattern, Location and Contact objects that participate in relationships as indicated in the conceptual model.

In order to satisfy the richness requirements, the CalendarX conceptual model features a novel kind of concept that is not present in other calendar models: SuperEvent. A SuperEvent object defines a potentially infinite series of Event objects via recurrence patterns. More precisely, the series of Event objects is generated on demand from EventRule objects, with each EventRule object being related to a Pattern object. The Pattern object defines a set of dates for Event objects, while the associated EventRule object defines common attribute settings that are shared by the Event objects generated by the EventRule object, such as startTime, endTime or location. A SuperEvent object may contain several EventRule objects, one for each combination of attribute settings that need to be represented.

The UML class diagram leaves room for interpretation regarding relationships between concepts. Hence, a few words to clarify our intentions: Associations (simple line symbols) carry explicit navigational arrows, specifying which objects in a relationship should be accessible from other objects. Further types of relationships are composition (“owns-a”, closed diamond symbol) and aggregation (“has-a”, open-diamond symbol). We require that composition relationships can be navigated in both directions, aggregation relationships just in one. The star occurrence operator always indicates unordered collections in our diagram.

In earlier work [BST07][PB09] we have discussed how to translate the constraints of a UML class diagram into XML Schema so that related objects that instantiate the class diagram correspond exactly to instances of the schema, as illustrated in Figure 2:

Figure 2: Correspondence between UML class diagram and XML Schema

We have extended this method of translation by ensuring referential integrity of relationships with XML Schema key constraints. More importantly, following ideas presented in earlier work [BDPT10], we are developing a meta model for the subset of XML Schema that we need, including a formal ASM specification of its validation rules and a DSL for representing the instances as XML documents [BS12]. The resulting XML Schema for CalendarX and an instance document are referenced in the supporting-materials section.

The XML Schema incorporates the principles of DDD. It is a direct representation of the calendar data model, as part of the CalendarX domain model.

This finalizes the modeling of calendar data as part of the CalendarX domain model.

Modeling CalendarX Functionality and User Interface

Our starting point for modeling the dynamics of CalendarX is the user interface. We model the views and activities that are available from the views. We continue to use class diagrams, now including methods, as a first modeling language.

Views

CalendarX is accessed via a number of pages or screens that offer information and choices of interaction.

The four main pages are DayView, WeekView, MonthView and RangeView. These four view pages display a calendar's event data for a specific date, for the seven consecutive dates starting from a specific date, for a specific month in a specific year and for an arbitrary range of dates, respectively. Note that we leave open the start date for a week (often Monday or Sunday) at this point; we leave details such as these for further refinement of the domain model. Pages DayView, WeekView and MonthView are specific cases of RangeView. Page RangeView references the (finitely many) Event objects that are to be displayed by a specific view.

Note that we describe the information that is needed to build the page and the information that is displayed on a page in a purely logical form for now. Questions of layout and methods of interaction are left to further stages of refinement.

In addition to the view pages, the full version of CalendarX has Edit pages that are capable of displaying calendar data and their relations for editing purposes. We leave modeling of Edit pages to future refinements. Questions of data representation will be addressed below.

We abstract page RangeView and indirectly the other view pages to an abstract page View that holds information and offers choices of interaction that are common to all view pages of CalendarX: A View object provides a status message and holds information about the current calendar, date info and further filter info. The date info is a combination dateInfo of day, month and year information that may be partial but must be consistent; it is used as potentially partial information to compute specific date info for specific types of view. The filter info filterInfo constrains the events that are to be displayed, for example according to category or venue.

Questions of authentification and authorization are left to further refinements of the domain model.

Hence, we need to extend our conceptual model with page types, as demonstrated in Figure 3.

Figure 3: Modeling pages

Interaction

The state of the system CalendarX comprises an object currentPage of type View, carrying page-specific information as indicated above. A Page object offers user selections: the next page type to be visited and which calendar, dateInfo and filterInfo values to use for the next page. These choices are stored in global attributes that we name nextPage, nextCalendar, nextDateInfo and nextFilterInfo.

Hence, we envision CalendarX to move, under user control, between control states that we label dayView, weekView, monthView, rangeView and view, according to the page types; we also have states start and quit. The choice of state is stored in nextPage.

When CalendarX enters the control state that is indicated by the current value of nextPage, information items nextCalendar, nextDateInfo and nextFilterInfo are also available. CalendarX uses this information to create a new View object of appropriate type, setting view attributes, computing specific date information from nextDateInfo, and computing specific Event objects from date information, nextCalendar and nextFilterInfo. It also computes a status message.

The system assigns the newly constructed page to currentPage, displays that page and awaits user input for user selections, which are initialized with their current values.

The user enters data and signals completion of selection, and the system responds with a new iteration. Alternatively, the user may signal the intention to exit the system by setting nextPage to quit, prompting CalendarX to quit operation.

Creating view pages involves computing the associated events. For example, the method events() for DayView uses the date attribute of type Date, the calendar attribute of type Calendar and the filterInfo of type FilterInfo of the object that it operates on. It calls a method getEventsForDay(date: Date): Event* on Calendar object calendar, filters them according to filterInfo and returns the result. The methods events() for WeekView, MonthView and RangeView delegate to events() for DayView, calling it repeatedly for each Date that is returned by general methods datesForWeek(startDate:Date): Date* and datesForMonth(monthYear:MonthYear): Date*, gathering the filtered return values of these calls into the result sequence of Event objects.

Getting the events for the week that starts at firstDay for Calendar object c filtered by filterInfo of type FilterInfo entails the following steps:

• Look for all SuperEvent objects se that are part of c.

• Compute all days d in the week that starts at firstDay.

• For each of these se objects apply getEventsForWeek(d).

• Filter the union of all the resulting sets of events according to filterInfo.

• Return the result.

If we complete this specification, we notice that we need a method matches(date:Date) for Pattern that tests if a Pattern object covers date.

We list below the methods that we have mentioned above, grouped by types:

• DayView

  • Constructor DayView(c: Calendar, dI: DateInfo, fI: FilterInfo)

  • setDate()

  • events(): Event*

• WeekView

  • Constructor WeekView(c: Calendar, dI: DateInfo, fI: FilterInfo)

  • setFirstDate()

  • events(): Event*

• MonthView

  • Constructor MonthView(c: Calendar, dI: DateInfo, fI: FilterInfo)

  • setMonthYear()

  • events(): Event*

• RangeView

  • Constructor RangeView(c: Calendar, dI: DateInfo, fI: FilterInfo)

  • setFirstDate()

  • setLastDate()

  • events(): Event*

• View

  • Constructor View(c: Calendar, dI: DateInfo, fI: FilterInfo)

  • setStatusMessage()

• Calendar, SuperEvent, EventRule

  • getEventsForDay(date: Date): Event*

• Pattern

  • matches(date: Date): Boolean

• Event

  • filter(filterInfo: FilterInfo): P(Event), where the returned set of Event objects P(Event) has at most one element

• Global

  • datesForWeek(startDate: Date): Date*

  • datesForMonth(month: Month, year: Year): Date*

Interim summary

What have we achieved so far? We have created a domain model for CalendarX that captures data and functionality, including abstract user interface, navigation and data access. We are now going to formalize the domain model with the goal of deriving an implementation for CalendarX based on XML technology.

Formalizing the CalendarX domain model as an ASM

We are looking for a methodology that embodies the DDD design philosophy in the target area of Web applications that are solely built with XML technology. We wish to formalize the domain model while keeping to the ubiquitious language that the domain model establishes.

We have recently become acquainted with the method of Abstract State Machines (ASMs) [BS03] that seems to be highly suitable, as explained above. So we have decided to explore this method for this project.

ASMs are virtual machines that capture state in the form of algebras. This means that an ASM defines a vocabulary of set and function symbols and that it specifies functions and constraints with the help of algebraic expressions over this vocabulary.

It is straightforward to translate our conceptual and page models into an algebraic vocabulary with type and identity constraints. For example, we will have set symbols Calendar, SuperEvent and String that denote pairwise disjoint sets. There is a function named Calendar.description with domain Calendar and range String. We use the standard object-oriented notation c.description() for Calendar.description(c). Setting the value for description at argument c in Calendar as “Anne's private calendar” is achieved by setting c.description()="Anne's private calendar", using standard object-oriented notation. This is called an update expression in ASM terminology. Updates are used to redefine functions at runtime and so change system state. Of course, we can reuse the function name description for other domains, including SuperEvent, since the sets that represent concepts are considered to be pairwise disjoint as long as they are not related by inheritance. In case of inheritance we employ the object-oriented semantics of overwriting methods and polymorphy.

The composition relationship between Calendar and SuperEvent is modeled by a function superEvents with domain Calendar and range P(SuperEvent), the power set of SuperEvent, that is reversible in the following sense: For any SuperEvent object se there is exactly one Calendar object c so that se is in superEvents(c). With this constraint, superEvents models precisely the composition relation that can be navigated in both directions.

The full translation of the conceptual and page models into an ASM vocabulary with constraints is referenced in the supporting-materials section. This section also specifies the constructor functions, methods and auxilliary functions that are listed above. These functions are static; that is, they are independent of system state. The ASM methodology considers static functions as part of the initial state and leaves open how and at what level of abstraction they are specified.

We note already, even before we have specified any changes of state, that the ASM notation is more precise than the UML class diagram notation, which required us to define constraints outside of the diagram that can be covered explicitly by the ASM notation. We will reap the full benefits of ASMs when specifying CalendarX functionality and user interface.

An ASM program is designated as an initial state. It is a collection of statements of the form

The semantics of such a statement are straightforward: If the Boolean condition condition is met, then state updates updates are performed.

Updates are changes in the ASMs algebra; that is, additions or deletions of elements to or from a set or changes in the definition of a function. For example, if we wish to add a new SuperEvent object se to a Calendar object c, we would redefine c.superEvents() as c.superEvents() ∪ {se}, writing this as an update statement

In ASMs, all updates of all statements whose condition is true are performed simultaneously (or not at all if the update instructions are inconsistens).

Before the next round of computations is performed, the ASM accepts user input: that is, specifically designated input variables are set from the outside.

Hence, the modus operandi of an ASM is in repeating phases. The machine starts in the initial state, with input variables set.

During each phase, it first executes the updates specified that apply in the current state and moves into a new state. Then, second, it accepts changes of the input variables from outside.

In the CalendarX ASM, we have input states nextPage with potential values start, dayView, weekView, monthView, monthView, view and quit as well as nextCalendar of type Calendar, which must be a calendar in the CalendarX database, nextDateInfo of type PartialDate, and nextFilterInfo of type FilterInfo.

Each phase of the ASM CalendarX program corresponds to one navigation step from one page to another. The input variable nextPage determines which type of page is to be built. The input variables nextDateInfo, nextCalendar and nextFilterInfo determine from what information it is built.

This is the CalendarX ASM:

The CalendarX ASM makes use of static constructor functions new DayView(), new WeekView(), new MonthView(), new RangeView() and new View() that we have already specified.

The CalendarX Implementation

Robles Hahn as part of his Bachelor Thesis [RH11] and a number of groups of students as work in the lab courses “XML Technology” in the academic year 2011/2012 have implemented CalendarX as a Web application, on the basis of a domain model, using only XML technology as indicated above.

Currently, we are exploring the ASM concept of refinement that derives the implementation in a more systematic way from the specification, in accord with the DDD philosophy. This involves mapping objects to XML represenations, methods to XQuery functions, and function calls and return values to HTTP request and response entities.

We are going to relate our experiences with this approach in an expanded version of this paper.

Conclusions and further work