排查 GDL 分析问题

以下信息介绍了在分析 GDL 文件时可能会遇到的意外行为的一些原因。

症状:包含架构文件,但分析程序发出错误消息,指出“找不到'ROOT'模板,GDL 条目不会被模板化”,并忽略架构。
解决方案:检查是否定义了根模板。 如果定义了此类模板,请确保#Include:schema.gdl 指令位于任何实例数据之前。 否则,分析程序将忽略架构。

症状:你在 GDL 文件中多次定义一个属性,我看到它只出现在 XML 快照一次。
解决方案:必须为 XML 快照中出现的任何属性定义模板快照多次。 必须定义 *Additive 指令。 否则,仅显示最新的定义。

症状:分析程序抱怨“[在模板:”{template name}“中定义的生产未满足实际构造.]”,并且似乎每个成员的出现次数都在生产定义的范围内。
解决方案:首先,使用 GDL 分析应用程序的 -i 选项检查绑定到每个 GDL 条目的模板。 绑定可能没有按照预期的方式发生。 如果绑定似乎已正常工作,请记住,生产中命名的模板实例和派生自命名模板的任何模板的任何实例都满足生产。 因此,如果生产指定只能存在特定模板的一个实例,并且实际数据文件包含派生自该模板的两个模板实例,则会违反生产。 即使派生模板重新定义 *Name 指令,也会跟踪模板继承。

症状:收到一条警告消息,该消息引用正在分析的 GDL 文件中不存在的 *InvalidCombination。
解决方案:GDL 分析程序在内部将 *Constraint 指令转换为 *InvalidCombination 指令。 因此,在转换后检测到错误时,消息将 *约束引用为 *InvalidCombination。 此外,*InvalidCombination 的每个元素在内部存储的顺序不一定是 GDL 文件中指定的顺序。

症状:将值宏引用替换为其定义的值时,会出现虚假的尾随空格。
解决方案:值宏定义包含尾随注释。 将注释移动到单独的行。 在大多数上下文中,分析程序对是否存在额外的空格字符不敏感。

症状:使用 *IgnoreBlock 构造围绕不符合的语法不会对分析器隐藏内容,因为语法错误仍会生成。
解决方案:*IgnoreBlock 的内容必须仍符合 GDL。 *IgnoreBlock 只会阻止其内容出现在内部数据树中,并阻止执行任何非预处理器指令。 若要真正隐藏某些内容,请使用预处理器条件。 如果隐藏的片段本身包含不应执行的预处理器指令,请在使用预处理器条件将片段括起来之前更改预处理器前缀。

症状:在使用 *PreCompiled 指定的文件中定义的功能、构造和属性不会出现在 XML 快照中,主机文件无法引用。
解决方案:此症状是设计使然。 只能将模板和宏定义存储在预编译文件中。

症状:不能引用模板、预处理器定义、宏或从使用 *PreCompiled 指定的文件中在其他位置定义的其他内容。
解决方案:此症状是设计使然。 预编译文件设计为独立且完全独立于主机文件的上下文。 若要访问另一个文件中定义的模板或其他内容,必须将#Include指令直接命名为该文件#PreCompiled文件中。 通过使用 (#Include 文件中的#Include) 来间接包含的内容, (即,) 的根预编译 (#PreCompiled) 文件可以访问嵌套#Include语句。 预编译文件可以使用其他预编译文件#Include) 包括 (。

症状:功能或选项不会按照定义它们的顺序显示在快照中。 或者,第一个选项未分配为默认选项。
解决方案:某些选项可能之前已在 GDL 文件的另一部分或包含在你查看的功能或选项定义之前处理的包含文件中定义。 处理的第一个选项成为第一个选项,处理的第二个选项成为快照中的第二个选项,依此而行。

症状:你收到一条警告消息,指出 GDL 分析程序找不到 *ElementType 指令引用的模板,但该模板已定义。
解决方案:*ElementType 指令只能引用声明为 *Type: DATATYPE 的模板。

症状:定义为 *FilterTypeName:“CODEPAGE_STRING”的属性的值未正确转换为 Unicode。
解决方案:如果在分析此属性时未定义 *CodePage 指令,则分析程序假定字符串已在 Unicode 中。 请确保 *CodePage 定义显示在任何CODEPAGE_STRING属性之前。

症状:将数组或复合数据类型模板中的 *RequiredDelimiter 定义为包含多个空格字符或制表符的序列,并且分析程序似乎无法识别实际数据,即使它完全符合模板定义。
解决方案:分析程序在内部将任意空格字符串 (空格或制表符) 转换为单个空格字符。 因此,检查值时,它不满足模板定义。 若要避免这种情况,请仅为 *RequiredDelimiter 指定一个空格字符,或者为 *RequiredDelimiter 使用非空格字符,并为 *OptionalDelimiter 使用空格和制表符。

症状:DOM 接口:Xpath 查询在快照 (找不到任何元素,例如 selectSingleNode (“/SnapshotRoot/GDL_ATTRIBUTE”) 不返回任何) 。
解决方案:Xpath 假定不带命名空间前缀的元素名称引用 null 或空命名空间,而不是默认命名空间。 快照定义默认命名空间,并且大多数元素属于默认命名空间。

若要使用 Xpath 访问这些元素,客户端必须先将此默认命名空间映射到 explict 前缀。 若要以这种方式映射默认命名空间,请使用文档 pbjects setProperty 方法。 需要设置的属性是 SelectionNamespaces。 使用此属性为默认命名空间分配一个 explict 前缀。 在快照,默认命名空间是以下 URI:

https://schemas.microsoft.com/2002/print/gdl/1.0

对 setProperty 的调用可能如以下代码示例所示:

XMLDoc->setProperty(L"SelectionNamespaces", "xmlns:gdl=\"https://schemas.microsoft.com/2002/print/gdl/1.0\"");

前面示例中的第二个参数实际上是 Variant,但为简单起见,省略了这种增加的复杂性。 引用默认命名空间中的元素时,Xpath 查询现在必须显式引用命名空间前缀 gdl。 然后,该查询将成为以下代码示例。

selectSingleNode("/gdl:SnapshotRoot/gdl:GDL_ATTRIBUTE")

症状:DOM 接口:nodeTypedValue 属性始终将值作为 BSTR 类型返回,无论其 xsi:type 如何。
解决方案:MSXML 4.0 的当前实现仅在使用数据类型定义 (DTD) 定义时识别数据类型。 GDL 分析程序使用 XSD,这是当前的 W3C 建议。

症状:包含 ANSI 值介于 0 和 0x19 之间的字符的带引号的字符串会导致 XML 分析错误 (,0x0a、0x0d和0x09) 除外。
解决方案:此错误是一项 XML 功能。 此类字符串必须使用 XML 的二进制或 binhex 数据格式来表示。 将来版本的 XML 可能接受包含这些字符的字符串。

症状:某些使用 PASSTHROUGH 或 XSD_DEFINED 数据类型定义的 XML 实例数据或架构在加载到 DOM 中时会导致 XML 分析程序或验证错误消息。
解决方案:使用 PASSTHROUGH 或 XSD_DEFINED 数据类型创建自己的 XML 会绕过 GDL 分析程序 XML 生成代码,并让你了解 DOM 分析器中 XML 和怪异之处。 在使用这些数据类型之前,应熟练掌握 XML 来处理此类问题。

症状:分析程序显示“Preface 不能与预编译文件一起使用”,但根文件不包含 #Precompiled 指令。
解决方案:#Precompiled 指令实际上可能位于前言本身中。 分析程序无法区分 GDL 内容是来自前言还是根文件。