0

我们处理基于文本的消息（非 XML）。我们的目标是验证消息，如果内容正确，则消息有效。我们开发了我们自己的用 XML 定义的语言来表达消息的规则。我们需要添加更复杂的规则，我们认为现在是时候寻找其他替代方案并使用真正的规则引擎了。我们支持以下类型的规则：

  • 值列表或正则表达式中的名称，例如 {SMITH, MOORE, A*}
  • 消息中存在名称-
  • 消息中不存在名称
  • if condition then name = John else name = Jane 请注意，条件很简单，不包含任何逻辑运算符。

我们需要支持这些类型的规则：

  • if then else 但条件包含逻辑运算符
  • for ...循环：
    • 对于消息中的所有客户，我们希望至少一位来自美国，至少一位来自法国
    • 对于消息中的所有客户，我们希望至少有五个来自美国并且每年购买超过 1000 美元
    • 对于姓名为 John 的任何客户，姓氏必须是 Doe
  • 姓名为 John < 15 的客户总数
  • 公司名称等于消息中其他位置的公司名称

规则将取决于我们处理的消息类型。因此，我们正在研究几种现有的解决方案，例如：

  • 杰斯
  • OWL（一致性检查）
  • Schematron（通过在 XML 中转换消息）

考虑到我们用 Java 开发，最好的选择是什么？要考虑的另一件事是我们应该能够进行错误报告，如错误描述、错误位置（行号和列号）。

4

2 回答 2

1

在我看来，您已经走在正确的轨道上；我的建议是：

  1. 使用解析器/解释器直接检查基于文本的消息，并对生成的对象应用规则。@Kdeveloper 建议使用JavaCC来生成解析器/解释器，我可以通过个人担保 ANTLRv3 来补充这一点， ANTLRv3是在 Java（以及其他语言中）生成解析器/解释器/转换器的绝佳环境。从那里，您可以使用 Jess 或其他一些 Java 规则引擎来验证您生成的对象。您也可以尝试将您的规则直接编码到解析器/解释器中，但我建议不要这样做，而是选择将规则分开以保持解析和语义验证步骤分开。
  2. 将基于文本的消息转换为 XML 以应用 Schematron 也是另一个可行的选择，但您显然需要解析文本消息以将它们转换为 XML。为此，我仍然建议查看 JavaCC 或 ANTLRv3，并可能填充可以编组为 XML 的预定对象模型（例如可以由Castor或JAXB从W3C XML Schema生成的对象模型）。从那里，您可以在生成的 XML 上应用 Schematron。
  3. 我认为转换为 OWL 是您建议中最棘手的选择，但可能是最强大的。首先，您可能需要一个本体术语 (TBox)（类、属性等）。将您的实例数据（ABox）映射到。从那里开始，一致性检查只会让你走这么远；您概述的许多想要捕获的约束根本无法在 OWL 中表示，也无法单独使用 DL 推理器进行验证。然而，如果你将你的 OWL 本体与SWRL规则结合起来（例如），你就有机会捕捉到你所概述的大部分规则类型。查看SWRL 中可用的规则类型和内置函数看看这对你来说是否足够表达。如果是，您可以使用具有 SWRL 支持的 DL-Reasoners，例如 Pellet或HermiT。请注意，像这些 OWL/SWRL 推理器的单独实现可能或多或少地实现了W3C 规范，因此您需要检查每一个来确定它们的适用性。
于 2010-09-29T00:03:48.560 回答
0

如果您的规则是静态的（即在编译时已知），您可以使用众所周知的 Java 解析器生成器：JavaCC。

于 2010-09-28T21:42:57.850 回答