推土机工程师指南

介绍

Xanadu®项目是最初的超文本项目，是Ted Nelson的创意，也是无数聪明人经过近60年的精心和热情工作的结果。 由于开发周期长，该项目产生并使用了许多重要性各异的想法，特别重要的想法有很多名字。 由于它的历史跨越了多个计算时代，因此该项目产生的曾经被认为是激进的想法已经变得司空见惯，而曾经很普遍的其他想法却被遗忘并再次变得激进。 在这段时间里，大多数公开的文档都是由Ted编写的，旨在供非技术或半技术的读者使用。

在花了数年的粉丝之后，我有幸在Xanadu上工作了五到六年，试图从分散的文档中整理出对该项目的总体思路。 这使我有幸能够向Ted要求澄清技术和哲学方面的问题，也使我更好地了解了不同的思想和术语如何适应不同的时代。

Xanadu在许多技术社区中声誉不佳。 部分原因是由于误导的流行，部分原因是关于该项目的1995 Wired文章实际上是不正确的。 但是，我认为一个更大的问题是该项目的趋势（在1980年代以前是正常的，但现在很奇怪）默认为保密（即使在表面上是非秘密的想法方面），并考虑以公关方式公开发布信息。 最终，这意味着大多数可用信息都缺乏技术细节，或者其技术细节被隐藏在对通用受众友好的领域后面。 除少数例外（例如Udanax Green / xu88的FeBe手册 ），没有针对工程师的完整，组织良好且公开发布的Xanadu概念说明。 副作用是，工程师无法理解某些想法如何融合在一起，并用他们已经熟悉的想法填补了解释中的空白。

Xanadu概念在很大程度上是一个替代（和外星）宇宙。 在许多情况下，它们的开发要比粗略的通用计算技术早，并且在Xanadu以前和现在的开发人员社区之外并未得到广泛的理解。

我的目的是在Ted找到我并邀请我参加该项目之前，写出我希望能够阅读的指南。 运气好的话，这将清除一些误解，介绍一些陌生的想法，并为有兴趣加入该项目的人员提供足够的背景知识，以便他们快速了解内部文档。

本文档并非旨在全面介绍Xanadu。 尤其是，我不会（也不会）回顾项目的长篇大论，尽管在适当的时候，我会提到开发某些东西的时间段，以便为特定的技术决策提供背景。 解释Xanadu的历史重要性以及对这些想法进行温和或逐步的介绍也超出了本文档的范围：有很多要解释的内容，而很少的时间，因此，我将专注于技术背景并假设读者已经具有熟悉Xanadu。 有关非技术性的介绍和简要的时间顺序，请参阅Ted的视频系列Xanadu Basics 。

我将只介绍我具有丰富知识的项目，无论是通过工作，咨询还是使自己沉浸在其文档中。 这在时间顺序上留下了很大的差距（例如xu92 / Udanax Gold），这意味着我无法充分涵盖2017年之后开始的项目（包括当前的基于Web的演示）。 由于它们的重要性，我将顺便描述一些我不了解的项目和想法，包括OSMIC，xu92和专门的xu88 enfilade类型（如POOMfilade）； 但是，我的简短描述不应被视为完整或准确的。 我将尝试清楚地标记这些情况。

在某些情况下，我已经独立编写了一些在Project Xanadu下开发的数据结构或算法的开源实现。 拥有这些链接时，我将提供它们的链接。 它们旨在作为教学辅助手段-明确的实现示例-经常缺少优化或与其他功能的集成； 因此，不应将它们视为完整或生产就绪的实现。

法律说明

Xanadu®，ZigZag®和易燃的X徽标是注册商标。 如果可能，我将使用以下通用术语：“ xanaologic”是指包含Xanadu想法的系统； “ translit”或“ transliterature”是指表示超文本或超媒体的Xanalogy系统； “ ZZStructure”是指在没有UI层的情况下ZigZag实现中的基础数据结构和功能。

虽然我曾经一次秘密拥有属于Xanadu项目的商业秘密，但据我所知，我在此所描述的任何内容都不受当前有效的商业秘密保护的约束。 此外，尽管我已经写了版权归Xanadu项目的代码和文档，但是我并不是基于该代码和文档编写该文档，而是基于我对它的记忆。 据我所知，这里没有任何解释是秘密的。

我在这里概述了一些与想法相关的实时专利。 交互式ZigZag界面已获得US262736B1的保护 ，该专利于2001年获得批准，因此应该在几年后过期（而非交互式ZigZag界面则完全不受专利保护）。 切片插层（联合多个独立的zz结构的一种方式）已在US8682884B2中进行了介绍 ，但未在本文档中介绍，因为在我从事该项目时，这是一个商业秘密。 它于2014年获得授权。跨窗口的专利有两个被放弃的申请： 一个是2008年 ， 另一个是2012年 ； 这些申请的存在代表了现有技术，应确保以后不会再为此技术申请专利。 自2017 年以来，在可导航的转换窗口上有一项专利申请 。最后， 在线支付系统上有过期的专利 。 根据我的经验，Xanadu创意的专利状态不会妨碍其独立实施：Ted通常很高兴看到他的创意得到认真认真的实施。

Xanadu项目并未正式为该文档提供任何祝福，任何不准确之处都是我的。 我不代表Xanadu项目或Ted Nelson。

空中概述：关键概念

关于Xanadu的工作可以分为两个一般领域：涉及超文本和超媒体的音译文学，以及涉及小得多的数据片段的ZigZag。 这些领域偶尔会相互作用（请参阅我在ZZOGL / FloatingWorld上的部分），但是在大多数情况下，所涉及的技术仍然是分开的，它们具有截然不同且几乎矛盾的关注点和理念。

如果我们想在普通计算领域中找到一个非常粗略的对等物，那么音译将是文字处理，而之字折线将是电子表格和数据库的使用。

跨文学的所有形式都涉及到主流计算所缺少或与之无关的几个概念：对不可变文档和源数据的唯一永久寻址，间接文档传递，可见连接和外部标记。 所有这些思想都源于一个基本思想：对具有永久地址的不可变字节序列的操作。

ZigZag的Universe基于特定的数据结构-电子表格的概括，其中单元格可以沿任意多个命名维度具有连接。

在本文档中，我将重点介绍音译，因为它具有较长的历史和更多的相关概念。 这也是大多数人将“ Xanadu项目”的名称与之联系在一起的原因。

可见的连接，AKA跨窗口：跨文化的重要UI概念

音译入门

译文学是以前被称为“超文本”的新名称。 特别是：这是一种思考文本和其他媒体的方式，并且是思考方式使之成为可能的一组操作和功能。 诸如万维网之类的非Xanalogic超文本系统在不理解或不实现某些核心思想的情况下实现了音译的一些更闪光的功能，因此，实现其他功能要么是不可能，尴尬或不可靠的。 由于这些非Xanaologic系统主导了有关“超文本”的讨论，因此我们更改了名称。

在后端，有三个音译原则：

1. 所有地址都永久固定在它们所引用的数据上
2. 所有元信息（例如链接，格式和重新排列规则）都与原始信息不同，因此，将其存储为具有不同地址的不同数据块
3. 所有操作对所有用户可用，因为没有任何操作具有破坏性

这以几种不同的方式震撼。 一种是间接文件传递。

间接文档传递是这样一种想法，即用户可见的文档是来自各种来源的材料组合的结果。 实际上，此方法的工作方式取决于实现方式，但是当前的方法（自xu92项目结束以来使用-自1990年左右开始成为主流）是EDL和ODL。 EDL和ODL是具有永久地址的数据块，与其他任何东西一样，但是它们由客户端以特定方式进行解释。

EDL（编辑决策列表）是一组“跨度”，即具有字节偏移量和长度的数据块的永久地址。 （在xu88中，跨度被称为'threespan'，因为它具有三个组成部分：地址，开始和长度。）跨度被提取并按照它们在EDL文档中出现的顺序组合在一起。 由此产生的科学怪人被称为“ concatext”（“连接文本”的portmanteau）。

ODL（覆盖决策列表）包含有关如何显示属于特定地址范围的内容的规则。 因为concatext绝对不应包含任何类型的标记（即使span和div标签也算作有关文档中哪些部分应该被整除的元信息），所以所有格式化都使用这些规则进行。 例如，所有字体信息都是由ODL提供的，该ODL将字体或强调样式分配给特定的文本范围。 ODL还包含有关链接的信息（通过声明一个或多个跨度通过某种链接类型的链接来连接）和格式（通过声明某些跨度应被解释为图像，视频，音频剪辑等）的信息。）有关文本对齐或分页符的信息也被编码到ODL中。

EDL提供了重新混合他人文档或创建自己的新版本的功能，而无需以未明确标记的方式存储原始内容的副本。 （ 作为优化的问题，本地缓存可以存储或提供流行的上下文，并逆向处理以产生带有孔的原始数据块。重要的是，将原始地址放置在规范上是可以的。）对不同来源的引用（引用）称为“包涵”（transliterature included）。

尽管人们希望文档的作者提供一个ODL及其EDL（如果需要），但这种配对只是一个建议：ODL是一组格式规则，用户可以覆盖每个规则。 。 此外，所有加载到系统中的ODL都充当查看任何文档的格式规则集。 这样，一个人可以打开许多不同的文档并查看它们的隐藏连接（如果很幸运，可以使用ODL显示这些文档或其源之间的链接）。

在前端，链接显示为已打开文档的连接跨度之间的桥梁（也称为梁）。 （在我研究的实现中，我们有一组可配置的规则，用于为链接的文本和桥指定特定链接类型的颜色，并从链接类型的哈希值中以程序方式生成颜色（如果该类型不在我们的链接中）。颜色数据库。）在打开的文档之间使用可见光束称为“可见连接”或“横穿窗户”。

每个可见文档都被认为是可编辑的，因为编辑这样的文档会生成带有不同地址的新版本。

转换实现之间的差异

Web引入后，寻址以及EDL和ODL的存储方式发生了很大变化。

Udanax Green / xu88于80年代在Autodesk上开发，并于1999年开放源代码发布，它代表了于1970年代在itty bitty机器公司开始解决的一组特定想法的高潮。 特别是，Green使用一种称为“ enfilade ”的数据结构-一种具有特殊提取规则的树。 该功能区与“ 不倒翁地址 ”（一个不倒翁地址）结合使用，该数字序列告诉服务器如何导航树。

每个树节点包含零个或多个编号的子树，并且每个叶包含一条信息。 服务器使用每个翻转开关地址来确定要导航到的子树，并且当该地址中的数字用完时，它会串联并返回所有子树的数据。

Green是为带宽，内存和处理速度较差的客户端设计的，因此努力在服务器上进行尽可能多的处理，并为客户端提供几乎随时可以显示的内容。

Udanax Gold / xu92是在Green之后开发的，使用了另一种称为Ent的结构。 不幸的是，Gold的完整资源尚未发布，我无法提供太多信息。 我曾经遇到一位主要作者 ，他告诉我，Gold支持加密签名链进行版本控制，其方式类似于区块链，但我无法证实这一点。

从1990年代开始，音译系统开始使用URL和HTTP进行寻址。 XanaduSpace及其后续版本XanaSpace使用了该系统，基于浏览器的OpenXanadu和当前基于浏览器的演示XanaduCambridge也是如此 。 这带来了一些问题。 不能保证通过URL寻址的数据保持静态—实际上，即使W3C坚持认为更改通过URL寻址的数据是粗鲁和粗鲁的，几乎所有Web内容都是动态的，并且站点上的内容已完全替换为常规内容。基础。 此外，托管用户内容既是技术问题，也是（使用DMCA）法律问题。 基于浏览器的音译系统还存在另一个问题：同源策略使转换来自不同域的内容变得困难。

在我自己的Xanaologic系统中，我更喜欢使用基于CAN / DHT的系统，例如IPFS。 使用IPFS的原型在这里 。

XanaduSpace和XanaSpace中存在的另一个概念是' permascroll '。 Permascroll唯一违反了数据块是不可变的规则。 它是内容的仅追加日志。 这样的想法是，在编辑时，任何键入的内容都将进入Permascroll，而EDL会将该内容从Permascroll中排除。

关于如何使用Permascroll与发布结合使用，有两个想法。 一个是有一个私人和公共的永久档案部门–换句话说，在某人自己的机器上编辑的内容将在私人的永久档案中有地址，但是发布文档的过程将附加私有的永久档案的所有部分。将该文档发布给公众，但已发布的EDL将对其跨度地址和偏移进行编辑以进行补偿。 另一个使用单个公共Permascroll，该公共Permascroll使用我稍后将在transcopyright标题下描述的方法进行加密，未发布的部分被视为“非出售”。

锯齿状和ZZStructure

ZZStructure相对简单：从数学上讲，它是带有彩色边缘的有向图，其中每个节点最多可以具有每种颜色的两个边缘-一个向外，另一个进入。我们称这些节点为单元，我们称其为边缘连接。 我们将颜色称为“尺寸”。 方向是“向后”（向外）或“向后”（向内）。

每个单元格除具有与其他单元格的命名连接对外，还具有内容（尽管该内容可以为空白）。

ZZStructure的另一种思考方式是，沿某个维度（称为“ 等级 ”）的每个单元游程都充当双链表，因此ZZStructure是对象的缠结，它们同时在不同的双链表上占据不同的位置。

有了这些基本规则，我们就有了一个数据结构，根据您的看法，它可以有效地表达大量不同的事物。

可以看到它的一种方法是，单元格受属性的影响，该属性由其沿维度的正向连接定义。 这类似于基于原型的对象系统，并且在XanaSpace和其他地方内部用作配置系统。

一种特殊的属性' clone '被特殊对待。 当您请求一个单元格的内容时，您将沿着“ d.clone”级别（即d.clone的“ head ”或“ clonehead ”）获得最坏单元格的内容。 克隆（定义为沿d.clone邻居相邻的单元格）被视为对其克隆头的引用。 由于属性可以是某些其他单元格的克隆，因此可以节省空间，或者属性可以引用可能独立更改的一大堆其他属性。

用作个人组织者，思维导图工具或数据库，此属性模型非常有用。 就实际使用ZigZag而言，它通常带有双窗格界面作为个人组织者。

ZigZag中可能会生成异常的结构。 例如， ringrank的等级是圆形的-没有头。 拉链列表是沿某个维度的一对等级，以及沿某个其他维度的连接-表示关联数组或其他某种对应关系。

目前，有两种官方认可的ZigZag实现可供公众使用：基于控制台的系统称为azz和一个图形系统称为gzz 。 在加入该项目之前，我曾从事两个与之字形对齐的项目： dimscape （图形化ZZStructure编辑器）和iX （玩具OS），其用户界面和磁盘格式受azz启发。

官方认可的实现倾向于具有双窗格界面，因为它们倾向于支持基于键盘的标准化接口系统KBLANG，该系统至少需要两个窗格。 KBLANG的基础是将QWERTY键盘分为两个方向盘（控制它们各自窗格中当前突出显示的单元格），并使用其余的键执行操作或切换可见尺寸。

KBLANG导航和命令键

已经做出了一些努力来开发原生使用ZigZag的编程语言，电子表格公式语言利用电子表格结构的方式。 有一些讨论， 在这里 ，并在这里是我的问题的贡献 。

版权

Transcopyright是一个概念，它从真正不了解其尝试操作的人那里得到了很多回击。 我将尽力解释它，特别强调我所看到的困惑。

Transcopyright是一种用于在音译系统中货币化或控制个人资料分配的系统。 它不是DRM，因为它将与对象相同的所有权规则应用于数据：一个人购买了东西，一个人永久拥有，包括重新混合和释放重新混合的权利。

它专门用于简化派生作品的版权谈判，并且使用与RiffTrax相同的模型：混音器为下载混音的人已经拥有的素材提供叠加或重新排列规则。 为此，它依赖于永久寻址。

从技术上讲，它是如何工作的：当发布受版权保护的作品时，会生成一个一次性的便笺簿，该便笺簿的长度与该作品中所有新出版的资料的长度相同。 资料通过该一次性垫加密，并且是公开的密文。 任何人都可以查看密文的任何跨度。 任何人想要查看纯文本的一部分，都必须向作者或某些受信任的甲骨文要求一次性使用该部分。

任何人都可以下载重新混音或编辑，但是查看者尚未获得查看许可的片段将是密文（受ODL条目的限制，该条目将其涂黑并提供有关如何购买其权利的信息）。 可以决定只为混音中存在的字节付费。 观看者已经拥有的东西的重新混合将不需要第二份副本。

一旦获得了纯文本的副本，便没有任何技术机制可以阻止您使用纯文本做您喜欢的事情。 但是，礼节规定您不得将明文或加密密钥分发到合理范围之外，并且此时会实施正常的版权法。 对于您尚未创建的材料，软件本身不提供代表您分发的功能。

ZZOGL / FloatingWorld

XanaduSpace和XanaSpace使用独特的系统处理显示，其中ZZStructure控制3d空间中对象的放置，形状，颜色和交互配置文件。 这称为ZZOGL（对于ZigZag OpenGL）或FloatingWorld（简称FW）。

FW是锯齿形调整浪节中提到的“财产导向”模型的一种极端形式。 在其中，单元格对应于对象头（围绕其合并的对象）或属性值。

从代表结构起点的单元格（zzogl头）开始，一维代表绘制顺序。 我们遍历此维度上的对象两次。 在第一遍中，我们计算大小和位置； 在第二遍中，我们使用计算出的尺寸和位置进行绘制。

每个对象相对于位置偏移DAG中某个其他对象的位置进行计算。 它的父级在三个维度上的大小乘以0到1之间的向量（“ parentcenter ”，即父级相对于我们移动的点），我们加上了增量 ，然后将其放置在我们自己的一个点上（尺寸*中心）。

pos = parent.pos+(parent.size*(parent.center-parentcenter))+delta-(size*center)

这种动态的相对定位可以表示对象之间相对复杂的关系。 我们使用它来显示音译系统和ZigZag系统。

有两种对象：

• 'groups'：不可见的虚拟对象，用于同时移动整个对象组
• '平板'：矩形棱柱
• “光束”：具有纯色的四角形二维形状
• 'tetroids'：纹理化的二维形状，形状像俄罗斯方块或文本段落（换句话说，一个矩形，顶部或底部最多有两个较小的矩形邻接）

不幸的是，要使OpenGL在3d对象之上渲染大量文本，同时又要有足够的响应能力以实时编辑该文本，这是一个棘手的问题，而我们却无法解决。 结果，XanaduSpace和XanaSpace从未发布过。

OSMIC

OSMIC是另一种文档版本控制系统—一种通用的基于日志的系统，用于任何字节序列的基于树的版本控制。 每个版本都是步骤列表中的一个地址。 步骤可以是以下之一：

• 在特定点插入字节
• 从特定点删除字节

一个版本的地址就像一个翻转者地址一样，是一个由句点分隔的数字序列。 每次创建新版本时，最后一个数字都会递增。 每次版本树分叉时，都会在末尾添加一个新的数字，从零开始。

尽管可以通过运行日志从头开始重建版本，但也可以通过将每个删除视为插入并将每个插入视为删除来倒回到特定版本。 OSMIC日志可能比它表示的字节字符串大得多，因此紧凑的表示很重要。 我不了解Xanadu中关于OSMIC期刊的紧凑二进制表示形式的任何工作。

我没有使用过OSMIC，但有一次建议XanaduSpace应该改用基于OSMIC的系统来存储ZZOGL系统的状态和历史记录（因此，所有显示和编辑文档所需的内部信息） 。

我已经编写了OSMIC的开源概念验证实现 。 它与较早的Xanadu内部实现不兼容。 我还为它提出了另一种高性能存储系统 。

文字翻译

存在几种用于音译编辑的系统，其中一些已经发布。 在我看来，他们都不满意。 所有这些都基于从现有文档中选择和重新排序跨度。 我的实现称为SPANG ，旨在与OpenXanadu一起使用。 XanaduCambridge 的系统不太复杂，更手动 。

我们提出了一个更自然的系统，其中可以将选定的文本拖出窗口以创建新文档，也可以将其拖动以捕捉到文档的末尾（或插入到文档的中间）以产生包含。 我们建议将选定的文本范围拖到另一个选定的文本范围之上，以在它们之间产生链接。

这样的系统需要一个环境，在该环境中，浮动的文档和文本可能会在小部件之间拖动-换句话说，我们正在使用的跨平台图形库不支持这种情况。

格式

我在Xanadu时，磁盘格式（用于ZZStructure，EDL和ODL的格式）一直在不断变化。 从我作为专业程序员的角度来看，有些人很糟糕。 大多数都是基于CSV或键值对。 在某些情况下，他们将CSV用于必填字段，并将键值符号用于可选字段。

我更喜欢将YAML或JSON的子集用于ZZStructures，因为ZZStructures非常适合该模型。 但是，由于这些结构具有明确的层次结构，因此存在争议。

一般而言，EDL格式是每个跨度一行，具有三重有序（地址，开始，结束）。 是否使用密钥因规范而异，如何（或是否）可以在不指定其长度的情况下指定整个文档。

一般来说，ODL是指向“链接”文件的地址列表，这些“链接”文件包含一个类型，后跟称为“ endsets”的部分，每个部分包含一个或多个span。 通常，链接具有一个或两个端点集。 如果单个终端的跨度不连续，则产生的光束类似于海星或手。 我主张使用任意多个端点集，每个端点集具有任意多个跨度。 我还主张零长度单面链接，我认为它像书签一样。 我在XanaSpace中将分页符实现为零长度的单面链接。

对于是否适合于支持某个文档的上下文的跨度，一直存在争论（如果是，如何指定跨度）。 Ted通常反对此功能，而我在EDL和ODL中通常都赞成此功能。

如果您打算实施Xanaologic系统，那么与现有格式的兼容性将不是问题：即使在项目内部也没有真正的标准。 但是，您应该考虑上述问题。

From: https://hackernoon.com/an-engineers-guide-to-the-docuverse-d080cdbb73a6