状态

我本希望在出版之前对这篇文章进行更多的润色，但我似乎做不到被抓住。。。总是有这么多新东西！

面向全球Web的SGML的一些背景

在1992年末和1993年初，我在HTMLDTD上做了很多工作当我在Convex在线文档组工作时。

开始时，有LineMode浏览器和NeXT实现，以及Web中的几个节点用一些对SGML的间接引用。我对SGML并不十分熟悉，但我非常熟悉文档交换的问题，我渴望将我的一些正式系统背景应用于该问题。

关于形式上不可转换的文档格式

我在文档交换方面的经验使我对文档进行了分类使用一些“可编程”和有些不是。最广泛使用的源格式是可编程的：TeX，troff、postscript等等。另一方面，有几个“静态”格式：纯文本、Microsoft RTF、FrameMaker MIF、GNU的TeXinfo、，

这种区别对于文件来说至关重要的原因交换是从中的文档中提取信息“可编程”文档格式相当于停顿问题。也就是说，它是任意困难的，不能在普通时尚。

例如，我猜想不可能编写一个程序将从TeX文档中提取第三个单词。这很容易80%的TeX文档的任务--跳过一些格式化内容并获取由空白。但“格式化内容”可能是一个从hyperation字典中生成100个单词。所以简单的对TeX源进行词汇扫描会发现一个单词不第三的打印时文档的单词。

这似乎是一个模糊而不重要的问题，但我向你保证将TeX表转换为FrameMaker MIF的问题与无法解决。

因此，虽然“可编程”文档格式具有以下优点可以在每个文档的基础上添加功能缺点是机器无法恢复这些功能，并且以自动方式翻译。

作为通信媒体的文档格式

如果我们根据传统的发送方/消息/媒体/接收方通信模型，我们可以看到文档格式捕获不同级别的消息“具体性”。

该信息以以下概念和想法的集合开始：发送方。为了进行通信，发送方和接收方必须共享一些语言。也就是说，他们都必须理解一些常见的符号以及这些符号结合起来代表思想的方式。这个发送者的工作是用通用符号和在媒体上表达它们——即“呈现”或“呈现”它们。这个媒体刺激接收者在他/她的身上重建符号大脑——也就是说，接受者“解释”或“识别”符号从介质中。这些符号与接受者的大脑，而接受者“获得信息”

通信介质通常是更多和混凝土介质较少。例如，人们首先在英语的符号学，然后将这些符号表示为语音或书写字符的序列。那些写的字符依次是线条、曲线、笔划和点。接受者然后将笔画组合成字符，把字符变成单词，把单词变成短语、句子、思想，想法等等。

最常见、最普遍的文档格式，纯ASCII文本，捕获或数字化书面字符级别的消息。PostScript将字符捕获为直线、曲线和路径。全球信息论坛format将文档捕获为像素数组。GIF在很多方面比纯文本更具表现力，仅限于96个ASCII字符的排列。

RTF、TeX、nroff等文档格式提供了非常复杂的文档作者表达想法的自动化技术。它一开始，看到纯文本仍然如此广泛地使用，似乎很奇怪。PostScript似乎是最终的文档格式它的表达能力基本上包括人类眼睛能够感知，但它是设备依赖的。

然而，如果我们看看将数据重新解释为从它们所代表的思想来看，我们发现纯文本非常重要首选，因为自动阅读纯文本比读取GIF文件（光学字符识别）或后记文档（停止问题）。最后，虽然源代码为TeX或troff文档可能与作者的想法，而PostScript允许作者非常精确控制和巨大的表达能力，所有这些文档最终捕获文档的图像，以便向用户演示眼睛。它们不会将原始信息捕获为符号由机器加工。

换句话说，在PostScript中呈现想法有助于解决信息过载的问题--它只会复合形势。

作为一个真实的示例，假设您在PostScript，并且您想要查找特定的信息作者可能把文档组织得很好，但是你必须打印出来才能使用这些线索。如果字符不是内核过多，您可能能够使用grep或病态WAIS索引然后，一旦你找到了看起来像postscript的代码对于一些相关信息，你会祈祷文件能够遵守Adobe文档结构约定，以便您可以选择包含所需信息的页面并查看该页面。

如果这太反常了，看看在大以TeX编码的技术论文集。许多作者使用LaTeX，您可以说服索引引擎进行筛选常见的LaTeX格式习惯用法——或者更好的是，权重标题，摘要等，比基于格式化习惯用法。虽然这个问题有启发式的解决方案这将以典型的80%/20%方式工作，一般解决方案是再次等效于停顿问题；例如，个人文档中可能有一些TeX编程，可以更改以索引引擎无法实现的方式显示单词的重要性才能理解。

SGML作为分层通信介质

那么，SGML在发送者/消息/媒体/接收者游戏中的位置是什么？

我将使用PostScript作为比较的基础。PostScript模型由一个功能强大且通用的二维成像模型，即用于指定集合的一组基本符号使用方便的计算技术计算二维点，以及构建复杂符号的通用编程模型那些原语。该模型广泛应用于以下问题排版，并且有一个体系结构（即一套众所周知的源于原语的符号），用于使用和构建字体。

为了传达由人类符号组成的信息PostScript中的通信，可以从一组众所周知的字体，或使用众所周知的字体创建新字体架构，或使用postscript自由绘制一些字符基元，或使用postscript绘制线、框、圆等原语，或在纸上涂鸦，扫描它，并转换使用postscript图像运算符的位。符号的空间是几乎是无限的，只要这些符号可以最终表达出来作为页面上的像素。

PostScript的独特功能（有时是一个优势其他人的劣势）是您是否打印并交付或者您发送PostScript，接收者将其打印出来结果是相同的一组图像。

另一方面，SGML模型没有指定通用目的复杂符号可以定义为原始符号。符号的含义可以在SGML中找到标准本身，或某些公共文件（可能是，也可能不是机器可读），或以某种特定于系统的方式，或由SGML应用程序。唯一真正的原语是字符和“非SGML数据实体”。

该模型规定文档由声明、序言和实例。声明以ASCII和指定序言使用的字符集和语法符号和实例。序言用标准语言表示，使用三角形中的句法符号，并指定一组实体以及实例可用的元素类型语法。

实例是元素、字符数据和实体的序列受序言中规定的语法和SGML的约束标准没有为实例指定任何语义或含义。

因此，要使用SGML进行通信，发送方首先选择一个字符集以及一定的加工量和能力。例如“我用ASCII编写，我永远不会使用超过40个元素名字符长”是可以在SGML中表示的一些信息宣言。[该标准允许SGML声明隐式由发送方和接收方商定，通常情况下是这样的]。

棘手的部分是序言，发送者给出了一个语法约束文档的结构。连同信息实际上在序言中用SGML表达，通常会有一些愤怒附加到元素类型的应用程序定义语义。对于例如，序言可以用SGML表示必须出现H2元素在H1元素的内容中。但是在一个H1通常显示得更大，被认为更重要的是应用程序定义。

一旦序言确定（这通常涉及大量在一些域——最后，在序言，允许在每个文档的基础上进行一些更改），发送方受限于组织的严格结构文档的符号和字符数据。另一方面，他/她一种自动化技术，用于验证他/她是否没有使用结构，因此可以确信文档可以由机器消耗和加工。

HTML DTD：虽然方便，但符合要求

HTMLDTD的设计约束

Tim对HTML的最初概念是，它应该是表现为RTF。与传统的SGML应用程序相比文档可能是批量处理的，并且复杂的结构是常态，HTML文档旨在以交互方式处理。以及基于相当平坦的所见即所得文字处理器的广泛成功段落结构证明类似RTF的东西适合各种各样的任务。

我了解了一些SGML，很明显WWW浏览器HTML的实现非常缺乏类似SGML实体的东西经理。SGML有一些句法上的不一致标准。而且它没有使用ID/IDREF特性，因为它应该具有。。。

然后，当我开始理解SGML及其所有缺点时，（谁的想法是将换行符的重要性附加到月亮？）我没有那么热衷于声明所有的HTML亵渎一个真正的SGML方式。

因此，我选择了在我的战斗中寻找SGML标准和“现成的”HTML。任务是：

查找一些DTD，以便绝大多数HTML文档相反，它的所有实例对现有WWW客户端有意义。

我努力解决以下问题：

• 我们应该坚持下去<！HTML文件中的DOCTYPE HTML SYSTEM>？什么如果有人在里面放一个实体声明？（这是否意味着WWW客户端必须能够解析SGML序言？
• 属性值的语法是什么？如果我们允许SHORTTAG YES，这意味着我们必须解析<em/这个/的样式标记也是？
• 我们可以在DTD中放置一些短的参考地图吗SGML解析器和当前的WWW浏览器可以做同样的事情换行？（即，我们可以用换行一个悬而未决的问题）
• 有标记的部分呢？短参考地图？
• 我们应该使用什么字符集？如何表达ISO-Latin-1在SGML声明中？作者应该如何表达“<”字符？这应该如何在DTD中表达？
• 如何在属性值文本中加引号？
• 如果没有使用最小化？
• 我可以把base64编码的东西放在CDATA元素中吗？我必须这么做吗当心<等？
• 我们如何将SGML和多媒体数据组合在同一数据流中？

我找到了一些问题的解决方案，并将其推到了其他问题上。我可能会应该在DTD中对折衷方案发表更多评论。但是我想将DTD简化为规范信息将信息性信息保存在其他文档中。

顺便说一句，我起草了一系列4到5份文件SGML的各种结构和句法特征——一种验证套件。我不知道它去了哪里。

我想回应Elliot Kimber对HTML DTD的批评张贴。

>在这篇帖子的底部是对>符合HyTime标准的HTML DTD。我没有修改>元素或内容模型。我没有添加任何>新元素。我只添加了几个属性列表>元素。>>我所做的最大更改是处理URL地址的方式。>为了使用HyTime（而不是特定于应用程序）>方法，我必须更改URL地址>从直接引用转换为实体引用，其中>实体的系统标识符是其URL地址。

我早就提出过这个建议，但蒂姆拒绝了。我记得，他说所有这些额外的加价都是浪费。一方面，我同意语言的目的是为了表达共同语言简洁地说，SGML/HyTime在这方面很差。上另一方面，一旦您选择了SGML，您可能会像罗马人一样。

>这使得>链接元素符合建筑形式和放置>以足够的间接性允许其他寻址方法>用于定位对象，而无需修改>链接，仅实体声明。

为什么修改实体声明比修改链接更容易？六分之一，如果你问我的话，还有半打。

>我使用SUBDOC实体>虽然我不是>当然这是最好的，但没有其他构造>同样有效的SGML。请注意，8879中的任何地方都有>定义作为SUBDOC参考的结果必须发生的事情，>除了建立了新的解析上下文之外。实际>SUBDOC参考的结果是一个风格问题>在WWW上下文中，它将导致检索文档>并在单独的窗口中显示。关键是>子文档引用在>链接的源和目标，即一个文档>指的是另一个人。还可以定义目标文档>作为一个数据实体，使用任何合适的符号（可能>如果是另一个SGML文档，甚至是SGML）。这可能更好>方法，我不知道。

我不期望数据实体/子文档实体的区别对当代WWW客户来说，这是一座豆山。我有兴趣知道这对HyTime引擎是否有意义。

>如果我重新设计HTML，我会添加直接支持>对于HyTime位置阶梯，至少使用nameloc，>notloc和dataloc寻址元件。然而，如果这些>元素是交换所必需的，它们可以被生成>使用>DTD如下，因此它并不重要。>

你能详细说明一下吗？如果我们将为“生成”兼容的SGML交换，我们不妨使用TeXinfo或类似的实用工具用于特定应用目的。

>这只是将HyTime应用于HTML的一次尝试。>我确信还有其他同等有效的（或更有效的）>可以采取的方法。给定当前功能>对于WWW，我相信有很多方法可以表达这种功能>使用HyTime构造。HyTime构造也可能表明>扩展WWW功能的有用方法，谁知道呢。

前几天，我终于真正阅读了HyTime标准clink和noteloc形式看起来最有用。我也对表达HTML中使用的一些“相对链接”习惯用法。（例如，我们如何使用HyTime表示HREF=“../foo/bar.html#zabc”游戏的目的是以这样一种方式进行标记逐字从一个系统复制到另一个系统（例如unix到VMS），并且正确的含义）

><!实体%URL“CDATA”>--术语URL表示CDATA属性>其值为通用资源定位器，>定义见ftp://info.cern.ch/pub/www/doc/url3.txt文件>        -->><!--=====================================================================>WEK：我已经将URL地址定义为一种符号，以便它们可以>然后在notloc元素中使用。>    =====================================================================-->><!NOTATION url PUBLIC“-//WWW//NOTATION url/通用资源定位器>/'ftp:info.cern.ch/pub/www/doc/url3.txt'>//英语“>>

好主意。

>><!实体%linkattributes>“NAME NMTOKEN#默示>HREF实体#隐含>>--===好=======================================================>>HREF现在是实体属性，而不是包含>URL地址。要使用URL地址创建链接，>声明SUBDOC或数据实体并使系统>标识符对象的URL地址：>><！实体mydoc系统“文件URL地址”SUBDOC>>>这种间接给事物：>>      1. 保护源中的链接不受>由于物理地址仅为>指定一次。

啊。。。现在我明白了……如果你有很多mydoc或部件的链接在mydoc中，只有一个地方定义了mydoc的位置。Nifty。

>>      2. 使用其他寻址方法的机会，包括>可能会将URL替换为ISO正式公共>标识符。>    =================================================================-->>>TYPE NAME#IMPLIED--引用数据的释放类型：>亲生子女、SIBLING、NEXT、TOP、，>定义、更新、原件等-->URN CDATA#隐含--通用资源号。唯一文档id-->TITLE CDATA#隐含--仅供参考-->METHODS NAMES#IMPLIED--对象支持的方法：>文本搜索、获取、标题-->--每周：-->链接名称#隐含>--链接端为本地链接取一个或多个NAME=值-->HyNames CDATA#FIXED“类型锚定URN DOCORSUB”>        ">

我原以为HyTime定义的是REFsomething和REFSUB。还是这些只是默认值？也。。。是不是HyNames认为本地工作是这样的吗？真见鬼！

>><!--=== WEK（周）==========================>>HyNames=属性将本地属性名映射到>协同响应的HyTime表单。>>Methods=属性有点令人费解，因为它实际上是>超链接表示/处理样式的一部分，而不是>锚的属性，但没有任何问题>在HyTime应用程序中包含特定于应用程序的内容。

1. 文件A说“点击此处[23]查看索引”
2. 用户单击
3. 客户端获取链接23，“http://host/index（主机/索引）"
4. 显示“封面”文档
5. 用户输入FIND abc
6. 客户端获取”http://host/index？abc"
7. 显示搜索结果

1. 文件A说“点击此处[23]搜索索引”
2. 用户单击
3. 客户端displayes“在此处输入搜索词：”对话框
4. 用户输入FIND abc
5. 客户端获取”http://host/index？abc"
6. 显示搜索结果

>我添加了LinkEnds=，以便各种链接元素>完全符合clink和ilink的形式。现场>LinkEnds=属性的不表示需要支持>但它确实使HTML更加一致>其他使用LinkEnds=属性形式的DTD。>>请注意，10744显示了ILINK表单的属性名称>为“linkend”，而不是“linkends”。我认为这是一个>打字错误，因为没有逻辑上的理由禁止多个锚点>从一个碰撞和缺乏它提出了一个不适当的要求>指定不需要的nameloc元素。无论如何，>应用程序可以将linkends=转换为linkend=加上>nameloc，所以在实践中并不重要。

>><!元素P-O空--分隔段落-->><!--=== WEK（周）==========================================================>>设计说明：这似乎是一种构建信息的笨拙方法。>人们希望段落包含内容。>>    ==================================================================-->

><!元素DL--（DT|DD|P|%超文本；）*>><!--    内容应匹配（（DT，（%hypertext；）+）+，（DD，（%hypertext:）+））>但混合内容很混乱。>  -->><!--=== WEK（周）============================================================>>设计说明：该内容应为：>><！要素DL--（DT+，DD）+>>    <!元素（DT|DD）-O（%超文本；）*>>>没有理由让DT和DD为空。也许有>对混合内容的问题有些困惑？有>这里没有。>>这些注释也适用于其他列表元素。>>    ====================================================================-->

我可能对混合内容感到困惑，但我理解的方式除非在可重复或组中，否则您不希望使用混合内容因为作者会把空白放在应该忽略的地方但不会的。

>><!-- 省略了字符实体。这些应该与>主DTD，以便特定应用程序可以定义其值。>ISO实体集可用于此。>  -->