为电子邮件创建标记语言会产生哪些技术问题？

Question

我想知道将标记语言与电子邮件相关联会产生哪些技术问题？在不检查语言的情况下，让我们假设存在一个假设的标记语言，其中包含以下条件：

• 它满足了在电子邮件中正确构建和定义内容的所有可能的用户代理需求。
• 它恰当地制裁了单个文档中的通信，以允许多个作者贡献来表示电子邮件线程。
• 使用标记约定将RFC 5322类似的标头数据正确地关联到文档中的每个通信实例。
• 它解决了与可访问性，语义以及仅限于标记技术本身的其他问题相关的所有可能问题。
• 它解决了应用层处理方面的所有可能的安全条件，并且绝对没有解决与传输相关的问题。
• 该语言可能会或可能不会以XML的衍生物编写，并且是可立即使用的XML派生技术。
• 语言实例需要先从用户代理进行验证，然后才能将其作为电子邮件传输。

有人说这个项目有哪些技术问题？这会给用户代理带来编程问题吗？这样的项目是否会证明与RFC 5322表单电子邮件不兼容，其中内容只有7位ASCII？这种技术会对电子邮件服务器造成损害吗？是否存在与此类项目相关的其他安全问题？关于这样一个项目，您对其他技术具体的一般想法是什么？请尽可能关注技术/编程，以保持答案和响应。我将对与商业意见或收养有关的任何评论进行投票。

Answer 1

作为一个语义难题，最棘手的问题之一是对数据含义的充分限制。假设你有无限的支持和合作，正如你的最后一句所暗示的那样。 :-)我认为单独的XML 仍然没有充分执行你最终想要的语义。遗憾的是，我不能快速地举例说明，而是说出袖口：

“GOK标记的内容必须是一个不大于前面FLOIT标记中包含的BREEP标记总数的整数”

是一条规则我不认为你很快就会通过XML验证来强制执行。 （我可能是错的;对我来说这是当天早些时候。）

这不是致命的，但它很难，而且不仅如此，它看起来很难。简而言之，您最终需要在任何努力中强制执行的语义将很快需要等效的一阶逻辑（如果不是二阶逻辑），这需要强大的描述语言。存在这样的语言（Common Logic会立即引起注意，OWL Full也是如此）......但是你需要一个kick-ass推理引擎来强制执行规则。

我说这很难说是因为不幸的原因让你接近你的禁止商业意见，但它仍然只是为了人为因素而提到。也就是说，根据我的经验，用户习惯于接近数据建模的关系代数方式所施加的限制，他们倾向于自然地遵循非常粗略的规则，例如“这个字段必须是整数，必须是一个字符串“，并且下意识地假设真实的语义将由人类眼球强制执行。换句话说，很难看出除了有效的单纯的语法执行之外还需要什么......但这只是我的经验;你的可能会完全不同。