使用 substitutionGroup 时可以强制使用标签结构吗
Can you enforce the tag structure when using a substitutionGroup
我目前有以下代码可以验证递归结构。每个级别都可以具有 substitutionGroup 中列出的任何元素名称。
<xsd:complexType name="Level1">
<xsd:sequence>
<xsd:element ref="Level2" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="nodeID" type="xsd:integer" use="required" />
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
<xsd:element name="Level2" type="Level1" />
<xsd:element name="Level3" substitutionGroup="Level2" />
<xsd:element name="Level4" substitutionGroup="Level3" />
<xsd:element name="Level5" substitutionGroup="Level4" />
以下代码使用此架构进行验证
<Level1 nodeID="3648" name="1" >
<Level3 nodeID="3649" name="1.1" >
<Level2 nodeID="3650" name="1.1.1" >
</Level2 >
</Level3 >
<Level4 nodeID="3651" name="1.2" >
</Level4 >
</Level1 >
我真的希望能够强制 Level2 始终在 Level1 中,等等,如下所示:
<Level1 nodeID="3648" name="1" >
<Level2 nodeID="3649" name="1.1" >
<Level3 nodeID="3650" name="1.1.1" >
</Level3 >
</Level2 >
<Level2 nodeID="3651" name="1.2" >
</Level2 >
</Level1 >
这可以使用替换组吗?或者这是我缺少的更简单的东西?
目标是针对相同的底层 complexType 进行验证,并且如果可能的话,在 XSD 文件中有一个有效元素名称列表。
主要限制是用户群需要不同的级别和级别名称。我试图让 adding/removing 级别的结构尽可能简单,并将它们的名称从用例更改为用例。
您可以将其视为缩进文档结构,其中每个级别都可以有不同的名称,例如章节、部分、段落。每个人都想以不同的方式命名他们的部分,并且可以或多或少地命名。
谢谢
首先,您的术语需要一些调整:
currently have the following code that will validate a recursive structure
那不是 代码,它是您的 XML 数据结构的架构。所以它是一个'XML Schema'。
它确实验证了递归结构,但您的目标文档结构实际上并不是递归的……稍后会详细介绍。
The following code validates using this schema
...那是 数据 而不是代码。它采用 XML 文档的形式。
其次,您的 XML 文档肯定不会使用您发布的 XML 架构进行验证,因为该架构不包含 <Level1>
.
的任何元素声明
不过,我想我明白你想做什么。你的方法很聪明,但它永远不会奏效,因为这不是替代组的设计目的。
您承认每个用户都需要不同级别的不同名称,因此您将被迫为每个客户生成 模式。那么为什么不生成整个XSD呢?
如果您想确保每个标签都具有相同的两个属性,那么您可以使用具有这些属性的抽象基类型。生成器可以为每个命名级别创建复杂类型扩展。但是,如果您要生成整个 XSD,那么生成属性和其他所有内容一样容易。
如果您想成为技术纯粹主义者,您可以使用文本模板引擎或(如果您使用 Java)使用 Eclipse EMF XSD 库来执行模式生成。
经过大量研究,我得出的结论是该模式可以工作,但不是我想要的原因。
substitutionGroup逻辑会将名称解析到下一层,看到新一层是substitionGroup,再解析。逻辑将继续这样做,直到找到 Level1 complexType。然后文档将被验证为 Level1,无论元素名称或父元素如何 - 只要它已解析。
This example is similar and leads me to believe this isn't possible
However, I'm still researching this concept. There is a sliver of hope
我目前有以下代码可以验证递归结构。每个级别都可以具有 substitutionGroup 中列出的任何元素名称。
<xsd:complexType name="Level1">
<xsd:sequence>
<xsd:element ref="Level2" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="nodeID" type="xsd:integer" use="required" />
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
<xsd:element name="Level2" type="Level1" />
<xsd:element name="Level3" substitutionGroup="Level2" />
<xsd:element name="Level4" substitutionGroup="Level3" />
<xsd:element name="Level5" substitutionGroup="Level4" />
以下代码使用此架构进行验证
<Level1 nodeID="3648" name="1" >
<Level3 nodeID="3649" name="1.1" >
<Level2 nodeID="3650" name="1.1.1" >
</Level2 >
</Level3 >
<Level4 nodeID="3651" name="1.2" >
</Level4 >
</Level1 >
我真的希望能够强制 Level2 始终在 Level1 中,等等,如下所示:
<Level1 nodeID="3648" name="1" >
<Level2 nodeID="3649" name="1.1" >
<Level3 nodeID="3650" name="1.1.1" >
</Level3 >
</Level2 >
<Level2 nodeID="3651" name="1.2" >
</Level2 >
</Level1 >
这可以使用替换组吗?或者这是我缺少的更简单的东西?
目标是针对相同的底层 complexType 进行验证,并且如果可能的话,在 XSD 文件中有一个有效元素名称列表。
主要限制是用户群需要不同的级别和级别名称。我试图让 adding/removing 级别的结构尽可能简单,并将它们的名称从用例更改为用例。
您可以将其视为缩进文档结构,其中每个级别都可以有不同的名称,例如章节、部分、段落。每个人都想以不同的方式命名他们的部分,并且可以或多或少地命名。
谢谢
首先,您的术语需要一些调整:
currently have the following code that will validate a recursive structure
那不是 代码,它是您的 XML 数据结构的架构。所以它是一个'XML Schema'。 它确实验证了递归结构,但您的目标文档结构实际上并不是递归的……稍后会详细介绍。
The following code validates using this schema
...那是 数据 而不是代码。它采用 XML 文档的形式。
其次,您的 XML 文档肯定不会使用您发布的 XML 架构进行验证,因为该架构不包含 <Level1>
.
不过,我想我明白你想做什么。你的方法很聪明,但它永远不会奏效,因为这不是替代组的设计目的。
您承认每个用户都需要不同级别的不同名称,因此您将被迫为每个客户生成 模式。那么为什么不生成整个XSD呢?
如果您想确保每个标签都具有相同的两个属性,那么您可以使用具有这些属性的抽象基类型。生成器可以为每个命名级别创建复杂类型扩展。但是,如果您要生成整个 XSD,那么生成属性和其他所有内容一样容易。
如果您想成为技术纯粹主义者,您可以使用文本模板引擎或(如果您使用 Java)使用 Eclipse EMF XSD 库来执行模式生成。
经过大量研究,我得出的结论是该模式可以工作,但不是我想要的原因。
substitutionGroup逻辑会将名称解析到下一层,看到新一层是substitionGroup,再解析。逻辑将继续这样做,直到找到 Level1 complexType。然后文档将被验证为 Level1,无论元素名称或父元素如何 - 只要它已解析。
This example is similar and leads me to believe this isn't possible
However, I'm still researching this concept. There is a sliver of hope