FLEXIBLE HUMAN SERVICE INTERFACES

Josef Spillner, Iris Braun and Alexander Schill

Chair for Computer Networks, TU Dresden, 01062 Dresden, Germany

Keywords:

WSGUI, Web Services, GUI generation, MDA techniques.

Abstract:

Dynamic web service invocation without special client software may help the adoption of service-oriented

architectures on the consumer stage. Ad-hoc usage of services requires a powerful set of concepts to visu-

alise the service input and output messages in a user-friendly, ergonomic and extensible way. Such concepts

are collected in a research effort named Web Service Graphical User Interface and are presented in the pa-

per in combination with an algorithm to combine the concepts into one imaginary GUI creation engine, for

which a proof-of-concept implementation exists. Extensibility is achieved by using implicit and explicit GUI

generation hints in addition to inference mechanisms based on the message structures.

1 MOTIVATION

WSGUI, or Web Services Graphical User Interface,

describes concepts on how to enrich data model

schema information in the context of web services so

that it becomes usable for humans in interactive sce-

narios. The core idea of WSGUI is that dialogs for

input and output of structured parameters can be gen-

erated dynamically. To achieve usable and appealing

GUIs, the formal message speciﬁcation will almost

never sufﬁce, hence there is a need for some addi-

tional data on how the GUI should be created. A col-

lection of concepts is presented which is believed to

achieve good overall quality without too much effort

in the creation of the additional data. There might be

other combinations of concepts, unknown as of yet,

but the ones presented here seem to be a good choice

given their properties: First, they follow the paradigm

of model-driven GUI design, making them suitable

for changes in the message parameters where the mes-

sage schema will take precedence over the GUI anno-

tations. Second, they can be used as needed, with few

interdependencies and the ability to incrementally im-

prove the generated GUIs without having to interfere

with the service functionality.

The term GUI shall be used in a wider sense and

will in most cases refer to generated dialogs or masks

for input and output of data.

The nature of web services in practice is that

they’re often described only syntactically, using

WSDL ﬁles which include schema information to de-

scribe the messages. This requires a mechanism to

make up for areas where the description lacks by

means of additional GUI generation hints.

WSGUI can therefore be thought of as a family of

different concepts which, when combined properly,

can lead to decent GUIs which are generated auto-

matically while still preserving an appealing look and

feel. Platform independence, integration with the sur-

rounding environment and consistency are further ad-

vantages of employing WSGUI concepts in applica-

tions.

The order of the sections of this paper is such that

the concepts are presented ﬁrst, followed by some

information on how they might interdepend on each

other. The introduction is complemented by a report

on progress since the initial presentation of WSGUI.

An implementation project and some related work is

presented afterwards.

Spillner J., Braun I. and Schill A. (2007).

FLEXIBLE HUMAN SERVICE INTERFACES.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - HCI, pages 79-85

DOI: 10.5220/0002366000790085

 SciTePress

2 WSGUI CONCEPTS

Concepts are introduced here as abstract steps which

are part of the transformation process from the web

service message structure to the GUI. All concepts are

realised through speciﬁc algorithms and ﬁlters as de-

scribed later. The software performing these steps is

named WSGUI engine, independent of how or where

it is actually implemented. For the GUI, any declar-

ative format can be the target of the transformation

process. WSGUI does not deﬁne a new abstract UI

description.

A number of concepts were present in the origi-

nal WSGUI proposal (Kassoff et al., 2003). Some of

them were found not to be needed anymore, while at

least two were found to be crucial so they’re included

in the following list. The others are the result of recent

work performed in this area by the authors. Reasons

for why to discontinue some of the concepts will be

given later.

The two mentioned original concepts are web

service description and form components, and can

be used by software implementations by reading in

GUIDD ﬁles, that is, GUI Deployment Descriptors

(Kassoff et al., 2006). New concepts added by the au-

thors include a strong inference mechanism, MIME

awareness, the user-toggle concept and templates.

Each of these concepts helps in shaping a better

GUI while still preserving the aforementioned prop-

erties. All of them are going to be presented in this

section.

2.1 Web Service Description

While most of the WSGUI concepts deal with individ-

ual service messages, being either input or output of

an operation, some of them deal with the global scope.

Navigating to the message requires presentation to the

user, too. This includes the selection of the service

and operation and passing this information to the user.

Such user interface elements include the internation-

alised representations of name, short description and

comprehensive help of both the services and their op-

erations, and also several details such as the caption

of the submission button for input forms.

While WSDL ﬁles can contain information such

as help texts, service providers usually do not trans-

late these texts. Especially for WSDL ﬁles generated

automatically by reﬂection from object code or pars-

ing of source code, it becomes necessary to supply ex-

ternal texts to overcome this limitation. The GUIDD

ﬁle format provides the

operations

section for the

task of including an arbitrary number of translated

human-readable texts.

2.2 Inference

Dynamic invocation of web services without any ad-

ditional GUI generation hints can still result in differ-

ent user experience, depending on how close the GUI

represents the message structures.

Instead of just providing simple form controls, say

string input ﬁelds, for all schema elements, a dynamic

invocation engine can already infer that some data

types require special treatment. For example, if a type

is restricted by an enumeration of values, only those

values should be displayed in a combo box, instead of

letting the user input arbitrary values. Likewise, an el-

ement which may occur n times as a child of its parent

element can be displayed as a list which may be en-

larged or shrunken within the occurrence constraints.

In addition, the XML Schema embedded into

WSDL ﬁles might provide valuable initial help texts

for each form control through its annotations. For the

captions of the controls, only the parameter name can

be used, which will not be suitable for human dis-

play unless they adhere to certain conventions (Steele

et al., 2005).

A still largely unexplored area is the coupling of

data types to semantics to generate widgets such as

password edits or multiline edits. None of them can

be inferred automatically. They are all based on the

string datatype as is the generic input widget, there-

fore form components are required in the meantime

to force their usage. Semantic annotations provide

implicit GUI hints, whereas form components are an

explicit concept. How to make use of semantic on-

tologies and how to address usability concerns is out

of scope for this paper and dealt with in other publi-

cations (Khushraj and Lassila, 2005).

2.3 Form Components

The main part of the GUIDD ﬁle format is about spec-

ifying abstract form components, each of which is

wrapping a speciﬁc GUI control, which can be used to

override decisions otherwise being made by the GUI

control inference mechanism. The GUI control fam-

ily currently proposed for GUIDD is XForms (Boyer

et al., 2006), which does however not imply any usage

thereof in the ﬁnal generated GUI.

Based on the message schema, both model and in-

stance addressing can be used to locate the position-

ing of the controls, with the latter one overriding the

former since complex data types can be in use mul-

tiple times. The need for instance addressing, which

was not present in the original GUIDD speciﬁcation,

stems from the fact that due to type deﬁnitions be-

ing either named or anonymous, there can be syntac-

ICEIS 2007 - International Conference on Enterprise Information Systems

tical ambiguities in the model which however lead to

no difference in the instance. For example, schema

elements might appear as anonymous child elements

in the schema XML, or they might appear as named

reusable types, but the instance XML will be the same

in both cases. Both addressing schemes use higher-

level XPath locators.

In case the instance data is restricted by an enu-

meration and this enumeration is likely to change or

even created dynamically, the concept of XForms ﬁl-

ters has been introduced. This replaces the previously

suggested method of dynamic enumerations, and is

also useful for handling translations. The GUIDD

speciﬁcation (Kassoff et al., 2006) contains advice on

how to handle ﬁlters. In the case of enumerations, it

ensures that instance data not yet covered by a select

item in the form component’s control gets added to

the control automatically, while in the case of trans-

lations, all translations which are not requested from

the engine will be dropped before delivery of the doc-

ument to the client.

2.4 Mime Awareness

Especially for output formatting, when receiving raw

data in base64 or hexadecimal encoding, a MIME

type can be speciﬁed to automate the display or other

further use of the data. Since this is only part of

WSDL on a message part level, but not available per

schema element, WSGUI needs to provide a way to

enhance the schema with this information. Some

MIME types might resolve to text effectively, for

example

application/pgp-signature

, but others

might lead to output format speciﬁc areas, such as

img

for

image/*

in a web context.

Recently, the proposed XForms 1.1 speciﬁcation

gained support for describing rich output formats for

its

output

control. Eventually, MIME awareness

might thus be realised using GUIDD’s form com-

ponents sections. However, to maintain backwards

compatibility, there is the OutputTypes section where

MIME types can explicitly be assigned to output form

controls.

2.5 User-toggle Concept

Since for some non-determinable widgets such as the

ones outlined above (password edit and multiline edit)

no automatic choice can be done, the inference mech-

anism would always return a generic input control.

In such a case, unless a form component is available,

the user should have the last word in these cases and

be able to override the inference mechanism’s choice.

This can be achieved by displaying a widget type-

toggling button beside the widget so that it can change

its type to whatever alternative might be available, and

does so by the user’s choice.

2.6 Templates

Form generation results in free-standing forms, con-

trary to the practical need of embedding such forms

into host documents such as web pages with custom

surrounding graphics. Templates make it possible to

deﬁne template pages with deﬁned positions for the

generated forms, and let the WSGUI engine output

the ﬁlled-in template instead of only a free-standing

form.

This concept is a web-speciﬁc extension to the

GUIDD format, as its usage is limited to web environ-

ments. However, experimental work has led to good

form integration with WSGUI templates and there-

fore environment-speciﬁc GUIDD proﬁles will likely

result from this work.

3 CONCEPT

INTERDEPENDENCIES

Now that the existing WSGUI concepts are deter-

mined, an algorithm is presented which is considered

a good compromise between automatic GUI genera-

tion and user-designed UIs. Depending on the efforts

for the creation of the GUIDD ﬁle, the result can be

either a generic and visually clumsy user interface or

a highly unique service-speciﬁc UI, and in most cases

will be in between.

3.1 Form Controls Generation

The proposed algorithm consists of a single recursive

function,

render()

, which takes as its parameter a

schema element, starting with the top-level element

of the complex schema tree. For each schema param-

eter, the best choice is selected for its representation

in the user interface, and the chosen UI element is

stored into a list as associated with the parameter. For

simplicity reasons, schema elements and attributes are

both treated as elements in the algorithm description.

FUNCTION rend er ( element ) :

IF is −complex ( element )

FOREACH chil d −element OF element

ren der ( child −element )

ELSE

IF form−component−found ( element )

f i l t e r −enumeration ( )

f i l t e r − t r a n s l a t i o n ( )

ui = apply−form−component ( )

FLEXIBLE HUMAN SERVICE INTERFACES

ELSE

IF mime−info −found ( element )

ui = mime−widget ( )

ELSE

f i l t e r −documentation ( )

IF inf ere nce −po s si b le ( element )

ui = in fer re d −co n tr o l ( )

ELSE

ui = generic −c on t ro l ( )

user −t og gl e ( )

s tor e ( child −element , ui )

The algorithm describes how to iterate over the

whole schema, recursively in the case of complex el-

ements which have child elements, to ﬁnd out all ele-

ments. For each of them, it is decided whether to use

explicit GUI information in the form of form compo-

nents if they are available, or to apply implicit hints

such as MIME awareness or possibly other semantic

annotations. If a form component can be located, the

contained form control must pass some ﬁlters, as is

implied by the form components concept. If neither

explicit nor implicit information is available, infer-

ence is the fall-back mechanism, which in some cases

needs to add a user-toggle button to the side of a con-

trol.

Most concepts are present in this algorithm. The

remaining ones deal with web service-speciﬁc infor-

mation such as operations and are handled outside the

scope of the creation of the form controls themselves.

The algorithm should instead be part of a pipeline

which lays out the list of form controls according to

how the GUI should eventually look like.

3.2 Pipelining the Concepts

While the presented algorithm transforms message

parameters into form controls, it barely covers lay-

out and geometry settings, that is, how to place the

controls onto the resulting GUI. The only way of in-

ferring those settings is to either build up a tree-like

view, with complex data types being containers for

simple types being represented as controls, or to use

generic schema-based GUI element positioning algo-

rithms as explored in (Kruschinski, 1999).

Since there is no predominant way of specify-

ing layouts, WSGUI does currently not include any-

thing else but an implementation-dependent tree lay-

out convention. The tree-like structure of the mes-

sages the forms are based on suggests that this is an

acceptable resolution.

The usage of explicit layout and geometry infor-

mation could well be seen as a second transformation

step in a pipeline, with the algorithm presented above

being the ﬁrst step. A third (and last) step would be to

integrate resulting forms into host documents, as de-

Figure 1: WSGUI engine as a pipeline.

scribed in the WSGUI templates concept entry. Fig-

ure 1 describes how the pipeline works. It is note-

worthy that not only the schema, but also related con-

text information such as operation-speciﬁc informa-

tion (name and submission URL) and the position in

a complex process, if any, are used to determine the

generated GUI.

4 COMPARISON TO THE

ORIGINAL WSGUI CONCEPTS

In 2003, the ﬁrst paper on WSGUI was published

(Kassoff et al., 2003), which outlined the basic ideas

present in current-day WSGUI research. However,

with other standards progressing fast, in particular

those in the area of XML, it was time to reconsider

the ideas of the paper and re-evaluate them for prac-

tical usage. The ideas will be listed, described and

evaluated in the forthcoming paragraphs.

Form Components as speciﬁed in a GUIDD ﬁle

are still considered a necessary WSGUI concept. Sev-

eral subtle differences to the original idea exist, such

as using XForms controls directly (apart from ﬁl-

tering) as opposed to merely borrowing from the

XForms syntax. The central idea of form components

is explicit assignment of visual controls to parts of the

data model. The reliance on XForms is discussed in

the section about the form components concept and

helps keeping WSGUI lean.

Form Navigation is an interesting concept which

can morph the UI around a selection between di-

rect editing, item selection and constraint-based query

views. The intended implementation looks doable,

ICEIS 2007 - International Conference on Enterprise Information Systems

nevertheless this feature is not included in the cur-

rent research since it requires additional work from

the authors of GUIDD ﬁles. The new concept of user-

toggle is a similar one, which stresses the choice on

the part of the user.

Variable-sized Lists is deﬁnitely needed for web

services which contain schema elements of varying

quantities. However, it was found that WSGUI en-

gines can automatically generate GUIs which take

care of adding and removing controls according to the

allowed range of quantity. For example, XForms pro-

vides the xf:repeat module which eliminates the need

to copy the functionality in the GUIDD ﬁle.

Virtual Operations are best implemented within

processes, and delivered transparently to the client as

part of a WSDL ﬁle by a process engine. Standards

such as BPEL, the Business Process Execution Lan-

guage, make it possible to build such virtual opera-

tions without the direct need for WSGUI concepts,

since the elements of a GUIDD ﬁle can refer to such

operations as well.

Dynamic Enumeration refers to special web ser-

vice method which return a list of all possible values

of a variable, for display in a non-editable drop-down

box or a similar widget. Value constraints are better

speciﬁed explicitly in a schema ﬁle as part of a sim-

ple type enumeration restriction. As before, GUIDD

form components can map to these lists of values,

but no special requirement is needed for the service.

XForms ﬁlters ensure that if GUIDD and the enumer-

ation instance data go out of sync, the resulting GUI

does still display formally correct choices to the user.

Therefore, the current GUIDD ﬁles do not need the

corresponding XML descriptions anymore, and web

services do not need to be enhanced with helper meth-

ods anymore.

Look-and-feel Stylesheets The task of the L&F

stylesheets is to convert an abstract user interface to

a concrete one. The wide adoption of abstract GUI

description languages such as XForms and our im-

plementation work has led us to believe that no such

stylesheets are needed per se as part of GUIDD.

To conclude this section, a number of concepts

could be saved, partially thanks to alternative ap-

proaches leading to similar or better user experience,

and at the same time leading to less work for both the

GUIDD authors and the service providers.

5 RESEARCH AND

IMPLEMENTATION PROJECTS

The failure of adoption of previous efforts similar to

WSGUI led to the conclusion that ﬁle formats like

GUIDD would only be deployed if sufﬁcient support

for it is available from software developers. The au-

thors of the paper will present their implementation in

this section, but also refer to others which share some

of the ideas.

5.1 Project Dynvocation

Most of the WSGUI concepts described above are

being implemented as part of Project Dynvocation

(Spillner et al., 2006). The Dynvoker servlet gener-

ates input forms and result pages on the ﬂy from web

services, using inference as heavily as possible and

applying GUIDD hints wherever they are available.

Most of the implementation work was aimed at

creating a servlet which produces XHTML pages with

embedded XForms. Thanks to the use of XForms

in GUIDD form components, the XForms controls

found in the GUIDD form components can be used

natively after the XForms ﬁlters have been applied.

As opposed to its predecessor, HTML forms, XForms

offers schema binding and thus also type safety and

separation of data from its presentation.

Its focus on inference makes it possible to invoke

web services without any additional information, and

already provides type safety and ﬂexibility in terms

of changing list sizes and user-toggle actions. Adding

a GUIDD will however greatly enhance the user ex-

perience. An editor for the creation of GUIDD ﬁles

has been developed as part of a thesis work of one of

the authors recently. It reuses some of the WSGUI

concepts to make the authoring process as simple as

possible. The decoupling of a web service descrip-

tion ﬁle (the contract) and GUI hints (the presentation

layer) greatly helps in authoring and customising the

latter.

However, Dynvoker is not limited to producing

XHTML pages for the interaction with simple web

services. A few extensions will be described now.

5.1.1 Existing Extensions to Dynvoker

The Dynvoker software has been extended to han-

dle complex service interaction scenarios like BPEL-

composed services. The work is called GUI4CWS

(GUI for Complex Web Services) (Bleyh, 2006) and

uses a subset of BPEL in combination with WSGUI

concepts to achieve goal-oriented workﬂows.

FLEXIBLE HUMAN SERVICE INTERFACES

Beside XHTML output, a way to create XSWT

dialogs for the Eclipse platform has also been worked

on. While the XHTML generation works mostly pro-

grammatically, the Eclipse dialog generation is per-

formed by a XSL transformation. However, not all

corner cases could be handled to full satisfaction.

Other projects (Moebius, 2006) also try to generate

GUIs from XML Schema or WSDL ﬁles purely by

applying a XML transformation and similarly leave

out the more complicated transformations. It remains

to be seen to which extent the logic behind the GUI

generation can be represented in a declarative trans-

formation document if the goal was to implement all

WSGUI concepts.

5.1.2 Details of the Gui Generation

Before a form is rendered by Dynvoker, the user is

guided to select a web service and an operation. All

of the navigational user interface elements are derived

from a navigation schema as well, thus re-using Dyn-

voker’s ability to generate dialogs for several target

platforms.

Hence, Dynvoker presents itself to the user with

an interface which is automatically generated from

an XML Schema ﬁle and the corresponding GUIDD

ﬁle. It allows the user to select a service by enter-

ing the URL of a WSDL ﬁle, possibly in combination

with a GUIDD ﬁle in addition, and some option but-

tons which will inﬂuence the generation of the GUI,

mostly to be able to see the difference between using

and not using any of the mentioned WSGUI concepts.

If no GUIDD ﬁle is speciﬁed, the whole GUI genera-

tion process relies on inference mechanisms based on

the information in the WSDL ﬁle.

After submitting the service selection form, the

GUI for the input message of the WSDL ﬁle is ren-

dered, and the user again ﬁlls out all of the ﬁelds.

Another submission action now invokes the service

using Dynvoker as a proxy, and returns the result to

Dynvoker. The results are then rendered as an output

form which is sent to the user.

Architecturally (ﬁgure 2), a DynvokerEntrance

object receives the parameters of the call, provid-

ing an abstraction layer between the Dynvoker im-

plementation as a servlet, portlet or library on one

side and the remaining parts on the other side. Dyn-

vokerCore as a state machine then takes over the pa-

rameters and dispatches the call as needed. In most

cases, an XFormsAdapter object will be called which

implements the ﬁrst step of the WSGUI pipeline.

This includes assigning form components to the in-

dividual parameters of the currently selected web ser-

vice message, calling XFormsFilter whenever trans-

lations need to be eliminated from the form controls

Figure 2: Dynvoker architecture.

or enumerations are transformed. To render a suitable

XHTML page which is to include the generated form

or to include the form into an existing template page,

XFormsHost can be called. This object also handles

the placement of the form controls into a tree layout.

5.1.3 Xforms Filters

As mentioned before, form controls are not eas-

ily suitable for dynamically generated list datatypes,

for which only the control’s name and help could

be given deterministically, while the values might

change. When they don’t change too often or some of

them are present in most invocations, XForms ﬁlter-

ing comes to the rescue. The graphics 3 shows how

a partially applicable form control deﬁnition is lay-

ered on top of the corresponding auto-generated form

control.

XPath expressions are used to match the related

XML nodes of both controls. Similar to how form

controls themselves are referenced using XPath ex-

pressions, name spaces are preserved and handled

correctly, making it a suitable mechanism even for

complex schemas.

The GUIDD extension proposed in the GUI4CWS

document for handling list types by introducing a

placeholder

tag is not necessary anymore

thanks to the ﬁltering concept.

Filters are also used in Dynvoker to hide all trans-

lations which are not requested by the client in la-

bels, help texts and hint texts. Additionally, they’re

also used to use existing XML Schema annotations as

help texts if no help text has been given for a control

through the GUIDD ﬁle.

5.2 Other Wsgui-related Projects

A project similar in its goals is the XML Forms Gen-

erator (Kelly et al., 2006), which is part of the Eclipse

framework. It already supports external translation

ICEIS 2007 - International Conference on Enterprise Information Systems

Figure 3: XForms ﬁlters.

texts, which matches the GUIDD facility of form

components, but also deals with rendering options. Its

focus on web services would make it an ideal candi-

date for using further WSGUI concepts so that those

issues found in real-world web services and GUI gen-

eration of their messages could be overcome.

An architecture for discovery and dynamic invo-

cation of services has been presented in (Steele et al.,

2005). It focuses on multimodal access more than on

in-depth discussion of GUI generation for visual ac-

cess, which is still the most important kind of interac-

tion between services and humans. Building a service

discovery model on voice recognition is another idea

present in this work, which will further help in ad-hoc

service usage. The presented way of generating the

GUI could proﬁt from employing WSGUI concepts,

as the ambiguity of WSDL parameter naming is ad-

mitted openly in this work. The proposed solution,

to adhere to naming conventions for WSDL message

variables, will hardly address internationalisation, as

opposed to WSGUI form components.

Departing from the initial focus on web services,

WSGUI concepts are already used in other areas such

as conﬁguration dialogs and printer dialogs, which

are generated automatically from the underlying con-

ﬁguration schema (Schumacher, 2005). The num-

ber of shared concepts is high enough to warrant a

broader scope of WSGUI, separating the web service-

speciﬁc concepts from the generic ones. The former

are centred around web service descriptions such as

the common WSDL (Web Service Description Lan-

guage), while the latter are focusing on the generation

of forms from the message, its parts and their data

types.

6 CONCLUSION

Interfaces between web services and humans are

clearly on the agenda of researchers and inﬂuence fu-

ture service development. The WSGUI concepts col-

lectively presented in this paper, while not completely

eliminating the need for custom interfaces to web ser-

vices, are powerful enough to make the dynamic in-

vocation of web services feasible. The conditional us-

age of implicit and explicit GUI hints are of great help

in separating the work of web service developers and

interface designers.

The Dynvoker implementation handles complex

datatypes and namespaces within the XML Schema

part of WSDL ﬁles, unlike many other implementa-

tions which are only suitable for relatively simple ser-

vices. Its output in the XForms format ensures type-

safe data submission. Finally, the rigorous use of WS-

GUI concepts including several best-effort strategies

when no implicit or explicit GUI generation hints are

provided lead to usable GUIs without much effort.

Implicit semantic-driven GUI hints will be one of the

main topics of research in the near future.

REFERENCES

Bleyh, N. (2006). Analyse und Vergleich von Ans

atzen zur

Einbindung von menschlichen Interaktionen in kom-

plexe Web Services. Master’s thesis, TU Dresden.

Boyer, J. M., Landwehr, D., Merrick, R., Raman, T., et al.

(2006). XForms 1.0 (W3C Recommendation), 2nd

edition.

http://www.w3.org/TR/xforms/

Kassoff, M., Kato, D., and Mohsin, W. (2003). Creating

GUIs for Web Services. IEEE Internet Computing,

7(4):66–73.

Kassoff, M., Spillner, J., et al. (2006). GUIDD: GUI De-

ployment Descriptor ﬁle format speciﬁcation, 0.99.5

edition.

Kelly, K. E. et al. (2006). XML Forms Generator. IBM

alphaWorks.

Khushraj, D. and Lassila, O. (2005). Ontological approach

to generating personalized user interfaces for web ser-

vices. Lecture Notes in Computer Science, 3729:916–

927.

Kruschinski, V. (1999). Layoutgestaltung graﬁscher Be-

nutzungsoberﬂ

achen. PhD thesis, Ruhruniversit

Bochum.

Moebius, J. (2006). xsdtransformer.

http://xsdtrans.

sourceforge.net/#xsd2fx

Schumacher, C. (2005). KXforms - automatic conﬁguration

dialog generation. aKademy conference.

Spillner, J., Bleyh, N., et al. (2006). Project Dynvocation.

http://dynvocation.selfip.net/

Steele, R., Khankan, K., and Dillon, T. (2005). Mobile

web service discovery and invocation through auto-

generation of abstract multimodal interface. itcc,

2:35–41.

FLEXIBLE HUMAN SERVICE INTERFACES