98.11.29  ( d7
To Ted Nelson Home Page
Back to "My Parallel Universe"

Data should in general be parallel, with side-by-side indexing and markup.  Side-by-side data structures make sense.  (See reference 1.)

This makes it possible, for example, to use separate marking streams for different purposes, independently applying them to the same original data: Unfortunately, the tradition is to jam the data all together, and the result is our messy file systems-- and worse, SGML and HTML.  The currently popular model of SGML (and its derivatives HTML, XML) scrambles together two intrinsically different kinds of data which are intrinsically parallel.  This mixing makes it impossible to switch between markup structures (as in the second illustration, above.)

Examples of parallel data in popular software

Some people have seen the advantages of parallel data structures.  One nice example is in the popular Eudora e-mail reader.  The PC version of this program maintains the original Unix file structure of concatenated emails, but then marks their beginnings (and other information) in a parallel stream, the .toc file (table of contents).  This is a nice example where the addition of a second parallel data stream allowed the first to be untouched.

A better-known, but less successful, example is the distinction in Macintosh files between "data fork" and "resource fork".  Unfortunately this distinction has ceased to have any coherent fixed meaning, and whatever it was originally intended to clarify has long since been muddied.
Deeper uses: The Xanadu® software family

The Xanadu family of data structures has always (at least since 1970) been designed around parallelism between contents and markup streams.  (We expect to publish the original design papers hereabouts shortly.)

Reference 1.   T.Nelson, ”Embedded Markup Considered Harmful”,  In XML: Principles, Tools, and Techniques (World Wide Web Journal 2:4, fall 1997).  This paper is also on the Web at