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

Domain-Driven Design and Domain-Specific Languages

Domain-Driven Design (DDD) [E04] is a design philosophy originally aimed at dealing with complex software projects. Primary focus is on the concepts and the functionality of the domain of the software; that is, the subject area to which the user applies the program. Concepts and functionality are captured in a model; that is, a rigorously organized and selective abstraction of the subset of domain knowledge that is relevant to the software.

One of the key points of DDD is ubiquitious language: Domain experts and software engineers use a common core subset of the domain language for communication, model and implementation, thus intimately connecting these two concerns.

DDD extends a design methodology that was propagated in the 1980s: Participatory Design [F88] [SchN93]. It does not only involve domain experts in requirement elicitation and system design but lets the domain model drive the whole software development process, up to the point that the implementation “becomes” the model. DDD enables domain experts to become more deeply involved into the software development process and eventually to develop their own software.

Domain-Specific Languages (DSLs) are programming or descriptional languages of limited expressiveness that target a specific domain. In the context of XML technology, schema-constrained sets of documents form DSLs that work particularly well within a DDD design philosophy, since their semantics are embodied in the domain model and their syntax can be derived from the domain model [BST07].

Abstract State Machines

The DDD design philosophy is open with respect to mechanisms with which to express the domain model and the connections to system articfacts. We wish for a more formal, precise specification of the domain model and the linking between the domain model and the implementation that is able to let the domain model shine through, in the spirit of DDD. Our methodology for these issues is inspired by Abstract State Machines (ASMs) [BS03]. ASMs are suited because of their notational flexibility, formal semantics, low protocol overhead and concept of step-wise refinement for linking levels of abstraction from high-level specification to low-level implementation.

ASMs are best described as abstract software systems (machines) written in pseudo code that operate on abstract data (state). ASMs are homogeneously used to formally represent artifacts on all levels of software development, from requirements (ground model) to implementation. The ASMs of the different levels are linked by so-called refinement steps.

The notion of abstract data and a pseudo code operational model make ASMs a natural tool for domain experts. Their precise semantics and notion of refinement make ASMs a great tool for formal specification of software systems and their development process that works well within the DDD design philosophy.

Implementation Technology

We employ a basic set of XML technologies to implement CalendarX: XML for representing data, XML Schema for constraining data, XQuery for querying and processing data, and XForms embedded into XHTML with CSS for the user interface.

We build Web applications from these technologies using the XRX architectural style, based on XForms on the client, RESTful communication and XQuery on the server. [McC07] [Mc08]. The greatest advantage of XRX lies in the use of a single data model (XML) on the server and on the client, eliminating the translation complexity of other architectures (zero translation). Other benefits of the XRX architecture include:

  • XML technology everywhere: The zero-translation architecture enables the use of XML technologies throughout the application. XML technologies suffice for all programming tasks on the client and on the server.

  • Declarative language on the client: The effort required to implement the client user interface is greatly reduced thanks to the declarative nature of XForms. The developer does not have to spend time programming complex scripts for user interface widgets and input validation. XForms just needs to be told what functionality is desired and the XForms engine will deal with buttons, text boxes, getting data to and from the server, and so on.

  • Separation of concers: The XRX architecture encourages separation of concerns in multiple ways. On the client, XForms keeps the user interface code separate from the data model. The REST interface keeps the server separate from the client, as both communicate with each other only through the interface.

The use of XML in all layers of a Web application makes use of the full potential of the XML family of technologies.

We deploy CalendarX on a software platform that consists of the following components:

  • Orbeon XForms processor: It runs within an Apache Tomcat Server and compiles XForms documents into XHTML and Javascript code that can be handled by any modern browser. We have tested it with Firefox and Chrome.

  • eXist XML database with XQuery support, running also within Tomcat.

  • Communication between these components and the browser via a REST protocol.

All CalendarX code is XML technology (XML, XML Schema, XForms, XHTML, and XQuery) that is linked to the domain model with ASM methods. No Web application frameworks, other object representations or programming languages are used. The CalendarX code truely expresses the domain model.

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

if condition then updates

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

c.superEvents()=c.superEvents() ∪ {se}

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:

if nextState==start then

currentPage=new View(nextCalendar,nextDateInfo, nextFilterInfo)

if nextState==dayView then

currentPage=new DayView(nextCalendar,nextDateInfo, nextFilterInfo)

if nextState==weekView then

currentPage=new WeekView(nextCalendar,nextDateInfo, nextFilterInfo)

if nextState==monthView then

currentPage=new MonthView(nextCalendar,nextDateInfo, nextFilterInfo)

if nextState==rangeView then

currentPage=new RangeView(nextCalendar,nextDateInfo, nextFilterInfo)

if nextState==quit then

stop operation

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.

Interim Summary

What have we achieved so far? We have created a domain model for CalendarX that captures data and functionality. And we have fully formalized the CalendarX domain model as an Abstract State Machine (ASM) while staying within the realm of the domain language. The result is what in the ASM world is called a ground model, an ASM that formally captures the requirements of a system.

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

  • The principle of Domain-Driven Design has been fully validated for this project.

  • Formal specification and systematic derivation of implementation make building CalendarX straightforward.

  • The implementations of CalendarX are largely platform independent, as far as XML technology is used. For example, Orbeon Forms and XSLTForms can be used interchangably as XForms processors. However, there are some areas where platform dependencies still exist, particularly in access to HTTP data via eXist extension modules to XQuery. We plan to address these issues with another standardized XML technology, namely XProc. With XProc, we can then also derive in a declarative way the orchestration of server-side functions from the ASM model, replacing some clumsy XQuery functions or Orbeon flowscripts.

  • ASMs have been useful for clarification but so far not mission-critical. We need to explore them further for step-wise refinement from ground model to implementation.

  • There is some functionality we want to add: First of all, editing of calendar data, which we expect to be mostly an XForms challenge. Next, printing of calendar data; student solutions use SVG, generated with XSLT; our idea is to make this technology accessible to domain experts via a higher-level graphics DSL. Finally, access control, concurrent access, safety and liveness requirements; the quickest route seems to recur to Web application frameworks as suggested by Davis [D11].

  • Our methodology might be best suited to smaller projects that are amenable to end-user computing. This is OK. After all, large publishing projects such as producing an electronic Oxford English Dictionary have not been exercises in personal publishing, either. Boundaries might be pushed a bit further with other case studies, though.

Appendix A. Supporting materials

Please visit http://www11.in.tum.de/lehrstuhl/personen/sayih/2012BalisageVol8-Bruggemann-Klein01-documents for supporting materials, particularly

  • XML Schema document for CalendarX plus an instance.

  • ASM model for CalendarX.

References

[B09] B.T. Bauman: Prying Apart Semantics and Implementation: Generating XML Schemata directly from ontologically sound conceptual models. Balisage 2009. Available from http://www.balisage.net/Proceedings/. doi:https://doi.org/10.4242/BalisageVol3.Bauman01.

[BD04] B. Brügge and A.H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns and Java. Second Edition, Prentice Hall 2004.

[BDPT10] Brüggemann-Klein A, Demirel T, Pagano D und Tai A: Reverse Modeling for Domain-Driven Engineering of Publishing Technology. Balisage Series on Markup Technologies 2010. Available from http://www.balisage.net/Proceedings/. doi:https://doi.org/10.4242/BalisageVol5.Bruggemann-Klein01.

[BS03] E. Börger and R. Stärk: Abstract State Machines. A Method for High-Level System Design and Analysis. Springer-Verlag 2003.

[BS08] A. Brüggemann-Klein, L. Singer: Hypertext Links and Relationships in XML Databases. Presented at Balisage: The Markup Conference 2008, Montréal, Canada, 2008, http://www.balisage.net/. Available from http://hyquery.ls-softworks.de/HyperDataSystemsBalisage2008.pdf. doi:https://doi.org/10.4242/BalisageVol1.Bruggemann-Klein01.

[BS12] A. Brüggemann-Klein and M. Sayih: Metamodels for XML Schema. Work in Progress 2012.

[BST07] A. Brüggemann-Klein, Th. Schöpf, K. Toni: Principles, Patterns and Procedures of XML Schema Design — Reporting from the XBlog Project. Extreme Markup Languages 2007. Available from http://conferences.idealliance.org/extreme/.

[C08] K. Cagle. REST-Oriented Architectures.. Balisage 2008. Available from http://www.balisage.net/Proceedings/. doi:https://doi.org/10.4242/BalisageVol1.Cagle01.

[DDL09] C. Daboo, M. Douglass, and St. Lees. xCal: The XML format for iCalendar. May 2011. Available from http://tools.ietf.org/pdf/draft-daboo-et-al-icalendar-in-xml-09.pdf.

[D11] C. Davis. Programming Application Logic for RESTful Services Using XML Technologies.. Balisage 2011. Available from http://www.balisage.net/Proceedings/. doi:https://doi.org/10.4242/BalisageVol7.Davis01.

[D09] B. Desruisseaux, ed. Internet Calendaring and Scheduling Core Object Specification (iCalendar). September 2009. Available from http://tools.ietf.org/pdf/rfc5545.pdf.

[E04] E. Evans: Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley 2004.

[FGSM04] G. Fischer, E. Giaccardi, Y. Ye, A.G. Sutcliffe, N. Mehandijev: Meta-Design: A Manifesto for End-User Development. CACM Vol 47 No 9, 2004.

[F88] Ch. Floyd: Outline of a Paradigm Change in Software Engineering. ACM SIGSOFT Vol 13 NO 2, 1988.

[F11] M. Fowler: Domain-Specific Languages. Addison-Wesley 2011.

[McC07] D. McCreary: Introducing the XRX Architecture: XForms/REST/XQuery. Available from http://datadictionary.blogspot.de/2007/12/introducing-xrx-architecture.html 2007.

[Mc08] D. McCreary: XRX: Simple, Elegant, Disruptive. Available from http://www.oreillynet.com/xml/blog/2008/05/xrx_a_simple_elegant_disruptiv_1.html 2008.

[PB09] D. Pagano and A. Brüggemann-Klein. Engineering Document Applications — From UML Models to XML Schemas. Balisage 2009. Available from http://www.balisage.net/Proceedings/. doi:https://doi.org/10.4242/BalisageVol3.Bruggemann-Klein01.

[RH11] J.T. Robles Hahn: An XML Application for a Calendar System using Domain-Driven Design. Bachelor Thesis. Technische Universität München 2011.

[SchN93] D. Schuler, A. Namioka (Eds): Participatory Design: Principles and Practices. Lawrence Erlbaum Associates, Hillsdale, NJ, 1993.