Menue
SRD

DialogML

project info
documentation

SEML

Mailinglists

DialogML specification and documentation
The introductory sections of the official specification are available for reading online. The complete specification is only available for downloading. The documented version is 0.96pre1. The introduction below is taken from the unfinished version 0.96pre2

The electronic version of the DialogML specification is distributed under the terms of the GNU Free Document License 1.1. All rights reserved by Dennis Heuer.

Table of Content
Introduction
The right approach
The different types of elements

The right approach
DialogML is targeted at being the solution for a variety of jobs that may be summarized with configuration, activation and maintenance. To fulfill the aim it must be designed as general and flexible as feasible. Consequently, the first criteria to mention is »being simple for being ingenious«. The more comfort the more restricted and bloated the standard.

On the other hand, the user interface must be as intuitive and comfortable as possible. To also fulfill this aim, DialogML assigns each modifiable parameter to a graphical component. The components (called widgets on some systems) are organized in one or several dialogs (frames or windows) which present the application. The design and concept (look & feel) of the application is conformant to the guidelines of modern graphical user interfaces and well known to the average user.

DialogML supports creating fairly complex applications though. This may turn into a problem and is often understood as a design flaw that must be eliminated by restricting the flexibility to some default dialogs, parameters and procedures. But, if the developer understands how to think in DialogML, he is enabled to develop problem-centered and high-quality interfaces with integrated tutorial system, parameter check, dummy testmode and the obligatory undo option. The enourmous amount of opportunities justifies the direction taken with DialogML.

The interface

DialogML is designed to support the definition of both a web-based multimedia interface and a simple, monochrome text-based interface. A simple text-based interface may not support two-dimensional layout but display one component a time while a web-based interface may even subdivide components within the same dialog. This is why the choice and the order of the components differs between the both types of interfaces. DialogML solves this problem in that it supports the definition of multiple sections in the same document. The interface is guided to the appropriate section over meta definitions.

The above implies that the component interfaces, the support for international languages, fonts, sorts of media, input and output devices and so forth may obviously vary too between the available interfaces. This is why DialogML provides a great selection of meta definitions for the definition of mandatory capability levels and more to enable the developer to define applicable compromises with the existing user interfaces.

The level of interdependencies

DialogML doesn't restrict the complexity of an application. This is completely in the hands of the developer. But it supports him--in the interest of the user--with language elements and strategies for being able to develop an individual but consequent and ergonomic interface.

Most of the provided strategies are well known from languages like XHTML or from graphical toolkits. The advantage of DialogML lies in the combination of such strategies for specifically the purpose of developing setup-alike applications. It is much easier to learn and use than a graphical toolkit, and it is far better prepared for sophisticated, event-driven processes than XHTML. DialogML works without low-level fiddling.

The execution

DialogML does not implement a single command. Instead, the developer may program own routines in an embedded language, or he uses the DialogML command element for defining commandlines for the commandline interpreter. He may use placeholders for user-defined parameters at runtime. The commandlines are executed on event--in parallel or in order.

The developer may define alert and confirmation dialogs for starting, skipping, monitoring or aborting an execution. DialogML also implements progress-meters of different style.

The innumerable possibilities

DialogML doesn't come without disadvantages. At runtime, the DialogML document has full control over the DialogML interpreter, and a criminal person could exploit this situation with manipulated documents. The system administrator must be extremely careful if he is about installing a DialogML interpreter. He must OVERTHINK ALL CONSEQUENCES before he gives access to an interpreter over the network--specifically the internet. Just a small security leak may be everything needed to offer intruders the opportunity to scratch his system entirely.

Consider that!