Beyond the "descriptive vs. procedural" distinction

Abstract

There has come to be a consensus that the “procedural vs. declarative” distinction is useful, if only as a rough guide, in the design of markup languages. To understand how and why this is the case, we need to ask questions that are usually left unasked when this principle is proposed, such as “is it the model (the schema) that we consider to be descriptive, or the tagged document? ” or, more deeply, “why do we validate our markup anyway?” A number of our fundamental assumptions are not always true. Sometimes a schema might be more than a “go/no-go gauge”, becoming a diagnostic and investigatory instrument. Sometimes marked-up documents look backward (as representations of something pre-existing), not just forward to processing. Sometimes semantic opacity is a feature, not a bug. In order to understand the power of markup languages, it is helpful to keep in mind that they are both technologies, and a species of rhetoric. New characterizations and categories of markup languages may help focus our design efforts.

Cite this work

No public copy is stored for this record, so only the metadata is cited.

Stored only when both papers are in the corpus — 20 citations exist upstream.

Papers that cite the same references — the relational fallback while embeddings are still backfilling.