We survey work on statically type checking XML transformations, covering a wide range of notations and ambitions. The concept of type may vary from idealizations of DTD to full-blown XML Schema or even more expressive formalisms. The notion of transformation may vary from clean and simple transductions to domain-specific languages or integration of XML in general-purpose programming languages. Type annotations can be either explicit or implicit, and type checking ranges from exact decidability to pragmatic approximations. We characterize

Abstract. In this paper we present the iData Toolkit. It allows programmers to create interactive, dynamic web applications with state on a high level of abstraction. The key element of this toolkit is the iData element. An iData element can be regarded as a self-contained object that stores values of a specified type. Generic programming techniques enable the automatic generation of HTML-forms from these types. These forms can be plugged into the web application. The iData elements can be interconnected. Complicated form dependencies can be defined in a pure functional, type safe, declarative programming style. This liberates the programmer from lots of low-level HTML programming and form handling. We illustrate the descriptive power of the toolkit by means of a small, yet complicated example: a project administration. The iData Toolkit is an excellent demonstration of the expressive power of modern generic (poly-typical) programming techniques.

A generic program is written once and works on values of many data types. Generic Haskell is a recent extension of the functional programming language Haskell that supports generic programming. This paper discusses how Generic Haskell can be used to implement XML tools whose behaviour depends on the DTD or Schema of the input XML document. Example tools include XML editors, databases, and compressors. Generic Haskell is ideally suited for implementing XML tools: .

Abstract. The iData Toolkit is a toolkit that allows programmers to create interactive, type-safe, dynamic web applications with state on a high level of abstraction. The key element of this toolkit is the iData element. An iData element is a form that is generated automatically from a type definition and that can be plugged in in the web page of a web application. In this paper we show how this automatic generation of forms has been implemented. The technique relies essentially on generic programming. It has resulted in a concise and flexible implementation. The kernel of the implementation can be reused for any graphical package. The iData Toolkit is an excellent demonstration of the expressive power of modern generic (poly-typical) programming techniques. 1

An XML data binding is a translation of XML documents into values of some programming language. This paper discusses a type-preserving XML-Haskell data binding that handles documents typed by the W3C XML Schema standard. Our translation is based on a formal semantics of Schema, and has been proved sound with respect to the semantics. We also show a program in Generic Haskell that constructs parsers specialized to a particular Schema type.

Datatypes which di#er inessentially in their names and structure are said to be isomorphic; for example, a ternary product is isomorphic to a nested pair of binary products. In some canonical cases, the conversion function is uniquely determined solely by the two types involved.

In this paper, we present a type system for typing Web applications in SMLserver, an e#cient multi-threaded Web server platform for Standard ML scriptlets. The type system guarantees that only conforming XHTML documents are sent to clients and that forms are used consistently and in a type-safe way. The type system is encoded in the type system of Standard ML using so-called phantom types.

When considering the past or the future, dear apprentice, be mindful of the present. If, while considering the past, you become caught in the past, lost in the past, or enslaved by the past, then you have forgotten yourself in the present. If, while considering the future, you become caught in the future, lost in the future, or enslaved by the future, then you have forgotten yourself in the present. Conversely, when considering the past, if you do not become caught, lost, or enslaved by the past, then you have remained mindful of the present. And if, when considering the future, you do not become caught, lost, or enslaved in the future, then you have remained mindful of the present. [14] Programmers in the real world wrestle everyday to overcome the impedance mismatch between relational data, objects, and XML. We have been working on solving this problem for the past ten years by applying principles from functional programming, in particular monads and comprehensions. By viewing data as monads and formulating queries as comprehensions, it becomes possible to unify the three data models and their corresponding programming languages instead of considering each as a separate special case. To actually bring this within the reach of mainstream programmers we have worked tirelessly on transferring functional programming technology from pure Haskell, via Cω to the upcoming versions of C ♯ 3.0 and Visual Basic 9 and the LINQ framework. Functional programming has finally reached the masses, except that it is called Visual Basic instead of Lisp,

Functional programming fits well with the use of descriptive markup in HTML and XML. There is also a good fit between S-expressions in Lisp and the means of expression in HTML and XML. These similarities are exploited in LAML which is a software package for Scheme. LAML supports exact mirrors of HTML 4.01, the three variants of XHTML 1.0, SVG 1.0, and a number of more specialized XML languages. The mirrors are all synthesized automatically from document type definitions (DTDs). Each element in a mirror is represented by a named function in Scheme. The mirror functions validate the XML document while it is generated. The validation is based on final state automata that are automatically derived from the DTD.

We take the term X/O impedance mismatch to describe the difficulty of the OO paradigm to accommodate XML processing by means of recasting it to typed OO programming. In particular, given XML types (say, XML schemas), it is notoriously difficult to map them automatically to object types (say, object models) that (i) reasonably compare to native object types typically devised by OO developers; (ii) fully preserve the intent of the original XML types; (iii) fully support round-tripping of arbitrary, valid XML data; and (iv) provide a general and convenient programming model for XML data hosted by objects. We reveal the X/O impedance mismatch in particular detail. That is, we survey the relevant differences between XML and objects in terms of their data models and their type systems. In this process, we systematically record and assess Xto-O mapping options. Our illustrations employ XSD (1.0) as the XML-schema language of choice and C# (1.0–3.0) as the bound of OO language expressiveness.