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.
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:
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.
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
objectsse
that are part ofc
. -
Compute all days
d
in the week that starts atfirstDay
. -
For each of these
se
objects applygetEventsForWeek(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 ofEvent
objectsP(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
thenstop 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.