It might be the case that you could have invented a new kind of publishing without making up a bunch of new jargon to name the concepts required to make it work, but the WWW definitely does not represent a proof that this is possible.
Quoting from https://dev.w3.org/html5/spec-LC/elements.html#classes:
> The style IDL attribute must return a CSSStyleDeclaration whose value represents the declarations specified in the attribute, if present. Mutating the CSSStyleDeclaration object must create a style attribute on the element (if there isn't one already) and then change its value to be a value representing the serialized form of the CSSStyleDeclaration object. The same object must be returned each time. [CSSOM]
The WWW-specific jargon here ("IDL", "attribute", "CSSStyleDeclaration", "declarations", "element", and arguably even "object" and "mutate") is only slightly less dense than the bit you quoted. The difference is that, because we've all spent the last quarter century embedded in the world it describes, its vocabulary is familiar to us. On the other hand, because Xanadu failed, its vocabulary is unfamiliar to us, so this passage seems opaque, even where it's doing things like helpfully restating what role a widdative function plays in generalized enfilade theory in case we've forgotten, or restating what the parts of a tumbler are for the same reason.
Incidentally, if the W3C spec you're looking at is ECMAScript, some of the authors are the same as the authors of the Xanadu spec.
— ⁂ —
What's being described in the passage you quoted is a tree structure over a sort of space of strings called "I-space" that is used to name documents or parts of them, similar to how URLs are used in WWW. The strings (tumblers) consist of sequences of nonnegative integers, rather than sequences of letters drawn from some finite alphabet like ASCII or Unicode. Tumblers have a lexicographical ordering on them: 1.2.3.4.5 comes after 1.2.3.4.4 or 1.2.3.3.6089235802, but before 1.2.3.4.6 or 2.0.0.0.0.
The tree is sorted by this lexicographical ordering, so in some sense all the data in the granfilade forms one single very long string, with tumblers like 1.2 or 1.2.3.4.5 identifying contiguous subsets of it. But this is not an advantageous way to organize the tree for efficient access, because 1.2.3.4 might be enormous compared to 1.2.3.3 or 1.2.3.5; instead the storage tree is made out of nodes that are about the same size at a given level of the tree, which are called crums. A crum might include all the data from 1.2.3.4.5 to 1.2.3.4.17 (exclusive); by subtracting these two tumblers we get its width ("wid"), which is 0.0.0.0.12, which means that it spans 12 leafnodes ("bottom crums"). If that crum and another crum that covers 1.2.3.4.17 to 1.2.3.4.25 (wid = 0.0.0.0.8) are the two children of a single parent node ("parent crum"), then the parent crum has a wid of 0.0.0.0.12 + 0.0.0.0.8 = 0.0.0.0.20.
This leaves us with the question of how to efficiently store this range "1.2.3.4.17 to 1.2.3.4.25". We could of course store it as a 12-byte sequence: 01 02 03 04 11 ff 01 02 03 04 19 ff or something like that. But there is obvious redundancy here, particularly considering the context of walking down the tree ("granfilade") from the parent crum which covers "1.2.3.4.5 to 1.2.3.4.25"; it's more efficient to just store the crum's wid 0.0.0.0.8, as something like 04 08, and its displacement ("disp") relative to the parent crum's starting point, which is 1.2.3.4.17 - 1.2.3.4.5 = 0.0.0.0.12, which is simply the tumbler sum of the wids of its preceding siblings.
This representation not only permits us to use less bytes, it also doesn't need to be modified if we graft a whole subtree from one part of the granfilade to another, or even (and I forget if they did this!) transclude it. And it allows us to build a nicely balanced sequentially-written B-tree of crums that guarantees logarithmic-time access to any atom, permits guaranteed crash recovery and even rollback, and doesn't have too much write amplification for localized writes. It doesn't handle large batches of dispersed writes as nicely as a log-structured merge tree does, but I don't think LSM-trees were known yet when they designed the granfilade.
Hopefully that clears things up a bit. I don't really understand Xanadu but I have spent a little time digging into it to try to figure it out.
— ⁂ —
In general enfilade theory there's the possibility of arbitrary sorts of "wids" and "disps" that are computed bottom-up and top-down in the same way: the wid of a node is computed by its widdative function from the wids of its child nodes, while the disp of a node is combined with the effective disp of its parent node to get its effective disp.
For example, if your wids and disps are numbers of bytes, you get a rope that efficiently supports indexing by byte offsets.
And if you use ordinary vector addition as the dispative function on a tree of nested windows, using the (x, y) offset of each window relative to its parent window as the disp, you can compute the absolute pixel offset for each window. You can almost do hbox/vbox layout this way, too: your wids are (width, height, orientation) triples, and your widdative function is something like
(x₁, y₁, H) ⍤ (x₂, y₂, H) = (x₁ + x₂, y₁ ∨ y₂, H)
(x₁, y₁, V) ⍤ (x₂, y₂, V) = (x₁ ∨ x₂, y₁ + y₂, V)
where ∨ is the pairwise max function; but at some point you need to turn a stack of hboxes into a vbox or vice versa, which either needs an N-ary widdative function (rather than binary) or a postprocessing function used once per node to flip the orientation.
As this indicates, the Xanadu folks were very much in love with the mathematical approach to software that seeks maximally general solutions to everything, and I think sometimes that didn't serve them well.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45... (Nelson 01999) may be interesting reading.