Program

Despite its many warts and wrinkles, SQL is undeniably a declarative success story. Teaching declarative thinking is often impeded by the procedural mindset of students originating from their early training almost exclusively in imperative programming languages. While SQL databases are optimized for executing SQL, students tend to write inefficient and clumsy code using disputable so-called “procedural extensions”. A few typical examples will be presented. While a limited kind of declarative constraints are supported in SQL, implementations generally fall short of the potential of database-wide declarative constraints. Some notions are illustrated by looking at declarative referential integrity, triggers as a poor substitute and an experimental RDBMS called “Rel”. As a concluding impulse for discussion, the presumed waste of talented declarative minds by the overpowering imperative bias in teaching is addressed.

The vision for a semantic web is over 20 years old, yet so little of our internet is currently using linked data. Where did it go wrong, and what can we do to revive this dream? Atomic Data is a modular specification that aims to make the semantic web achievable again through a developer-friendly ecosystem of tools that enable high data interoperability and return ownership back to the user.

Data is an abstraction. In order to transfer it or talk about it, the abstraction has to be represented using some notation. The design of notations is a neglected area of study, yet the designs affect both what you can represent, and what you can do with what is being represented. XML is currently the most suitable and flexible of the available notations for representing data abstractions, and yet it has restrictions and some shortcomings that get in the way of properly representing abstractions. This paper discusses the issues, and reflects on which aspects of XML get in the way of abstractions.

XML is top down oriented. In a DTD, an element type declaration specifies what content the element may contain, but in no way you can constrain in what context that element may be included. In document oriented languages, where mixed content is typical, it is worth looking up. By seeing in what way an element may occur in its potential parent elements one can classify elements. It raises questions like: is it "suspicious" if an element may occur in the mixed content of some elements, and in the element content of others? Is it suspicious if an element that may occur in mixed content has itself element content? What kind of elements occur in a repeatable OR group? What elements can serve as word boundaries? What does a SEQ group "mean"? Two sequence paradoxes will be mentioned, and by taking as an example both the content and the parents of the "paragraph next door" element we will find that what should be the second most used element in any document instance is actually missing in most industry standard markup languages.

ERP and business systems around the world are having to interconnect more today than ever before. Changing one's system to address interoperability can be a disruption and a risk. The four-corner model for document exchange addresses this in an interoperable network by requiring users' network representatives to exchange the semantic content of documents using a single declarative syntax. For business documents, multiple global networks have chosen the OASIS Universal Business Language (UBL) semantic library and XML syntax between access point network representatives. This is a model any industry sector can adopt to introduce successful interoperability into legacy environments.

The Extensible Markup language (XML) provides a way to share information with tagging specific to content domains, rhetorical forms, or other needs. By contrast, HTML markup is evolved synergistically with Web browsers in mind, and the tagging is largely specific to browsers. Although EPUB was (is) based on XML, it's also based on HTML: it uses XHTML for the documents. As a result, there is little to no support for domain-specific markup, and the ebook experience seems unimaginative, constrained by the intersection of Web browsing and content silos. What might happen if there could be communities evolving domain-specific markup for electronic texts? For 3D models or live mathematics, for poetry, for music and musical scores inside books? For context-specific dictionaries and glossaries, for per-chapter tables of contents and wayfinding cards, and so much more. Is there any way to enrich ebook readers in this direction?

In this presentation we want to explore some aspects of the XProc 3.0 language that could be considered as declarative, while pointing out some other aspects that are potentially not. For doing so we will build the case by looking at some common patterns relevant to pipeline authors. Stating that a programming language is "declarative", is not just a claim in computer science. It also has practical consequences. It is generally understood that declarative programming languages are easier to use and do allow people to solve problems in a shorter amount of time compared to other programming paradigms. Claiming that a programming language would be "declarative" implies that its use has commercial advances over other approaches to solve the same problem. The question whether XProc 3.0 is a declarative language is, to our knowledge, rarely addressed. Control structures like p:choose or p:try in XProc 3.0 might raise doubts about the declarative nature. On the other hand, the level of abstraction in XProc's step infrastructure might at least hint to declarative features. We felt that this tension offered enough motivation to give it some further thoughts. This presentation will not take the computer science theory route. Instead, we will focus on user experience while solving problems with XProc 3.0.

Over the last few years, “Tools for thought” has become a hot concept among software makers. We’ve seeing a surge in note-taking apps and knowledge management tools presenting themselves as TFTs. But there’s a strange paradox here: taken at face value, the phrase “tool for thought” doesn’t have the word ‘software’, ‘computer’ or ‘digital’ anywhere in it. It sounds like an idea that belongs to philosophy and cognitive science department, rather than computing. How and when did it become intertwined with computers? What are we to make of all the software upstarts identifying with this movement? And how can we push beyond them into a new generation of computational tools for thought?