1

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

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

话虽如此，这样的项目与哪些技术问题相关？这会给用户代理带来编程问题吗？这样的项目会被证明与内容仅为 7 位 ASCII 的 RFC 5322 形式的电子邮件不兼容吗？这样的技术会被证明对电子邮件服务器有害吗？是否存在与此类项目相关的其他安全问题？您对此类项目的其他技术特定的一般想法是什么？请尽可能以技术/编程为重点的答案和响应。我将对任何与商业意见或采用相关的评论投反对票。

4

1 回答 1

0

作为一个语义专家，最麻烦的问题之一是对数据含义的充分约束。假设你有无限的支持和合作，正如你最后一句话所暗示的那样。:-) 我认为单独的 XML仍然不能充分执行您最终想要的语义。遗憾的是，我不能很快举出例子来说明，但即兴发言：

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

是一条规则，我看不到您很快就会通过 XML 验证强制执行。（我可能是错的；对我来说现在还早。）

这不是致命的，但它很难，不仅如此，它看起来很难。简而言之，您最终需要在任何努力中实施的语义将很快需要等效于一阶逻辑（如果不是二阶），这需要强大的描述语言。存在这样的语言（Common Logic 立即浮现在脑海中，OWL Full 也是如此）......但是您需要一个出色的推理引擎来执行规则。

我说这看起来很难，因为不幸的是，这些原因与你的商业观点很接近，但如果仅仅是为了人为因素，它仍然值得一提。也就是说，根据我的经验，用户已经习惯了关系代数式处理数据建模的方式所施加的限制，以至于他们倾向于自然地坚持非常粗略的规则，例如“这个字段必须是整数，必须是一个字符串”，并下意识地假设真正的语义将由人类眼球强制执行。换句话说，除了有效地执行句法之外，很难看到需要其他任何东西……但这只是我的经验；你的可能完全不同。

于 2009-08-27T14:16:45.680 回答