Authoring XML Documents with XHTML and MATHML Support

Since the late 1970s, a large number of scientific documents have been authored in TeX or its derivations such as LaTeX. These typesetting systems allow anybody to write highquality books and articles. But the TeX syntax is not compatible with HTML or XML. So the WWW consortium\u27s answer is MathML. The primary goal of MathML is to enable mathematical documents to be communicated, exchanged, and processed on the Web. Therefore, MathML documents are usually embedded with XHTML documents. Currently, there are several XHTML+MathML editors. The most popular editors use two common approaches. The first approach offers a WhatYouSeeIsWhatYouGet (WYSIWYG) interface. But experts often find it is difficult to have precise control. For example, font attribute is determined by the direction of the mouse movement during the event of insertion. The second approach uses a textbased form. The entire document is presented as a treelike structure. The treelike structure is unintuitive and extremely inefficient to comprehend, particularly for twodimensional structures such as tables or equations. Here, I present a WhatYouSeeIsWhatYouNeed (WYSIWYN) editing interface that satisfies the needs of experts who have knowledge of XHML+MathML. The WYSIWYN interface is presented in a form that simultaneously makes editing operations unambiguous and that looks recognizable. It avoids unexpected errors by showing enough structure, but still maintain enough visual presentation to avoid confusion. This report presents a test bench, an XHTML+MathML editor with a new navigation model that demonstrates the WYSIWYN user interface. Similar to a WYSIWYG editor, XHTML+MathML documents can be visualized during editing, and users can check the current XPath position by viewing the status bar. In contrast to the WYSIWYG editor, the new approach offers users the ability to view local structure of the current element with a selected style. In this way, users can magnify any ambiguous positions and still be able to visualize mathematical documents. In addition, the test bench offers multiple WYSIWYN modes with different levels of magnification

A practical guide to computer simulations

Here practical aspects of conducting research via computer simulations are discussed. The following issues are addressed: software engineering, object-oriented software development, programming style, macros, make files, scripts, libraries, random numbers, testing, debugging, data plotting, curve fitting, finite-size scaling, information retrieval, and preparing presentations. Because of the limited space, usually only short introductions to the specific areas are given and references to more extensive literature are cited. All examples of code are in C/C++.Comment: 69 pages, with permission of Wiley-VCH, see http://www.wiley-vch.de (some screenshots with poor quality due to arXiv size restrictions) A comprehensively extended version will appear in spring 2009 as book at Word-Scientific, see http://www.worldscibooks.com/physics/6988.htm

Using Markup Languages for Accessible Scientific, Technical, and Scholarly Document Creation

In using software to write a scientific, technical, or other scholarly document, authors have essentially two options. They can either write it in a ‘what you see is what you get’ (WYSIWYG) editor such as a word processor, or write it in a text editor using a markup language such as HTML, LaTeX, Markdown, or AsciiDoc. This paper gives an overview of the latter approach, focusing on both the non-visual accessibility of the writing process, and that of the documents produced. Currently popular markup languages and established tools associated with them are introduced. Support for mathematical notation is considered. In addition, domain-specific programming languages for constructing various types of diagrams can be well integrated into the document production process. These languages offer interesting potential to facilitate the non-visual creation of graphical content, while raising insufficiently explored research questions. The flexibility with which documents written in current markup languages can be converted to different output formats is emphasized. These formats include HTML, EPUB, and PDF, as well as file formats used by contemporary word processors. Such conversion facilities can serve as means of enhancing the accessibility of a document both for the author (during the editing and proofreading process) and for those among the document’s recipients who use assistive technologies, such as screen readers and screen magnifiers. Current developments associated with markup languages and the accessibility of scientific or technical documents are described. The paper concludes with general commentary, together with a summary of opportunities for further research and software development

Affichage et manipulation interactive de formules mathématiques dans les documents structurés

Afficher des formules mathématiques et interagir avec ces formules sont des atouts primordiaux pour les outils informatiques dédiés aux mathématiques. Dans ce rapport, nous faisons un bilan des outils existants puis nous décrivons FIGUE, moteur d'affichage interactif incrémental et bidimensionnel, développé à l'INRIA, pour obtenir une bibliothèque dédiée au développement d'éditeurs de documents structurés et d'interfaces graphiques. Enfin nous montrons un exemple d'utilisation de FIGUE, dans le cadre du développement de preuves mathématiques sur ordinateur

User Interfaces for Theorem Provers: Necessary Nuisance or Unexplored Potential?

This note considers the design of user interfaces for interactive theorem provers. The basic rules of interface design are reviewed, and their applicability to theorem provers is discussed, leading to considerations about the particular challenges of interface design for theorem provers. A short overview and classification of existing interfaces is given, followed by suggestions of possible future work in the area

The usability of software for authoring and editing

This research investigates some of the reasons for the reported difficulties experienced by writers when using editing software designed for structured documents. The overall objective was to determine if there are aspects of the software interfaces which militate against optimal document construction by writers who are not computer experts, and to suggest possible remedies. Studies were undertaken to explore the nature and extent of the difficulties, and to identify which components of the software interfaces are involved. A model of a revised user interface was tested, and some possible adaptations to the interface are proposed which may help overcome the difficulties. The methodology comprised: 1. identification and description of the nature of a ‘structured document’ and what distinguishes it from other types of document used on computers; 2. isolation of the requirements of users of such documents, and the construction a set of personas which describe them; 3. evaluation of other work on the interaction between humans and computers, specifically in software for creating and editing structured documents; 4. estimation of the levels of adoption of the available software for editing structured documents and the reactions of existing users to it, with specific reference to difficulties encountered in using it; 5. examination of the software and identification of any mismatches between the expectations of users and the facilities provided by the software; 6. assessment of any physical or psychological factors in the reported difficulties experienced, and to determine what (if any) changes to the software might affect these. The conclusions are that seven of the twelve modifications tested could contribute to an improvement in usability, effectiveness, and efficiency when writing structured text (new document selection; adding new sections and new lists; identifying key information typographically; the creation of cross-references and bibliographic references; and the inclusion of parts of other documents). The remaining five were seen as more applicable to editing existing material than authoring new text (adding new elements; splitting and joining elements [before and after]; and moving block text)

Creating and Maintaining Consistent Documents with Elucidative Development

Software systems usually consist of multiple artefacts, such as requirements, class diagrams, or source code. Documents, such as specifications and documentation, can also be viewed as artefacts. In practice, however, writing and updating documents is often neglected because it is expensive and brings no immediate benefit. Consequently, documents are often outdated and communicate wrong information about the software. The price is paid later when a software system must be maintained and much implicit knowledge that existed at the time of the original development has been lost. A simple way to keep documents up to date is generation. However, not all documents can be fully generated. Usually, at least some content must be written by a human author. This handwritten content is lost if the documents must be regenerated. In this thesis, Elucidative Development is introduced. It is an approach to create documents by partial generation. Partial generation means that some parts of the document are generated whereas others are handwritten. Elucidative Development retains manually written content when the document is regenerated. An integral part of Elucidative Development is a guidance system, which informs the author about changes in the generated content and helps him update the handwritten content.:1 Introduction 1.1 Contributions 1.2 Scope of the Thesis 1.3 Organisation 2 Problem Analysis and Solution Outline 2.1 Redundancy and Inconsistency 2.2 Improving Consistency with Partial Generation 2.3 Conclusion 3 Background 3.1 Grammar-Based Modularisation 3.2 Model-Driven Software Development 3.3 Round-Trip Engineering 3.4 Conclusion 4 Elucidative Development 4.1 General Idea and Running Example 4.2 Requirements of Elucidative Development 4.3 Structure and Basic Concepts of Elucidative Documents 4.4 Presentation Layer 4.5 Guidance 4.6 Conclusion 5 Model-Driven Elucidative Development 5.1 General Idea and Running Example 5.2 Requirements of Model-Driven Elucidative Development 5.3 Structure and Basic Concepts of Elucidative Documents in Model-Driven Elucidative Development 5.4 Guidance 5.5 Conclusion 6 Extensions of Elucidative Development 6.1 Validating XML-based Elucidative Documents 6.2 Backpropagation-Based Round-Trip Engineering for Computed Text Document Fragments 6.3 Conclusion 7 Tool Support for an Elucidative Development Environment 7.1 Managing Active References 7.2 Inserting Computed Document Fragments 7.3 Caching the Computed Document Fragments 7.4 Elucidative Document Validation with Schemas 7.5 Conclusion 8 Related Work 8.1 Related Documentation Approaches 8.2 Consistency Approaches 8.3 Compound Documents 8.4 Conclusion 9 Evaluation 9.1 Creating and Maintaining the Cool Component Specification 9.2 Creating and Maintaining the UML Specification 9.3 Feasibility Studies 9.4 Conclusion 10 ConclusionSoftwaresysteme setzen sich üblicherweise aus vielen verschiedenen Artefakten zusammen, zum Beispiel Anforderungen, Klassendiagrammen oder Quellcode. Dokumente, wie zum Beispiel Spezifikationen oder Dokumentation, können auch als Artefakte betrachtet werden. In der Praxis wird aber das Schreiben und Aktualisieren von Dokumenten oft vernachlässigt, weil es zum einen teuer ist und zum anderen keinen unmittelbaren Vorteil bringt. Dokumente sind darum häufig veraltet und vermitteln falsche Informationen über die Software. Den Preis muss man später zahlen, wenn die Software gepflegt wird, weil viel von dem impliziten Wissen, das zur Zeit der Entwicklung existierte, verloren ist. Eine einfache Möglichkeit, Dokumente aktuell zu halten, ist Generierung. Allerdings können nicht alle Dokumente generiert werden. Meist muss wenigstens ein Teil von einem Menschen geschrieben werden. Dieser handgeschriebene Inhalt geht verloren, wenn das Dokument neu generiert werden muss. In dieser Arbeit wird das Elucidative Development vorgestellt. Dabei handelt es sich um einen Ansatz zur Dokumenterzeugung mittels partieller Generierung. Das bedeutet, dass Teile eines Dokuments generiert werden und der Rest von Hand ergänzt wird. Beim Elucidative Development bleibt der handgeschriebene Inhalt bestehen, wenn das restliche Dokument neu generiert wird. Ein integraler Bestandteil von Elucidative Development ist darüber hinaus ein Hilfesystem, das den Autor über Änderungen an generiertem Inhalt informiert und ihm hilft, den handgeschriebenen Inhalt zu aktualisieren.:1 Introduction 1.1 Contributions 1.2 Scope of the Thesis 1.3 Organisation 2 Problem Analysis and Solution Outline 2.1 Redundancy and Inconsistency 2.2 Improving Consistency with Partial Generation 2.3 Conclusion 3 Background 3.1 Grammar-Based Modularisation 3.2 Model-Driven Software Development 3.3 Round-Trip Engineering 3.4 Conclusion 4 Elucidative Development 4.1 General Idea and Running Example 4.2 Requirements of Elucidative Development 4.3 Structure and Basic Concepts of Elucidative Documents 4.4 Presentation Layer 4.5 Guidance 4.6 Conclusion 5 Model-Driven Elucidative Development 5.1 General Idea and Running Example 5.2 Requirements of Model-Driven Elucidative Development 5.3 Structure and Basic Concepts of Elucidative Documents in Model-Driven Elucidative Development 5.4 Guidance 5.5 Conclusion 6 Extensions of Elucidative Development 6.1 Validating XML-based Elucidative Documents 6.2 Backpropagation-Based Round-Trip Engineering for Computed Text Document Fragments 6.3 Conclusion 7 Tool Support for an Elucidative Development Environment 7.1 Managing Active References 7.2 Inserting Computed Document Fragments 7.3 Caching the Computed Document Fragments 7.4 Elucidative Document Validation with Schemas 7.5 Conclusion 8 Related Work 8.1 Related Documentation Approaches 8.2 Consistency Approaches 8.3 Compound Documents 8.4 Conclusion 9 Evaluation 9.1 Creating and Maintaining the Cool Component Specification 9.2 Creating and Maintaining the UML Specification 9.3 Feasibility Studies 9.4 Conclusion 10 Conclusio