如何找出XSD文件依赖项

时间:2017-10-17 08:54:45

标签: xml xsd schema

我想存储解析特定XSD文件所需的所有XSD文件。 This answer表示我们应该查找xs:includexs:import属性。

但是元素内部使用的命名空间呢?通常,根元素(模式声明)具有多个名称空间声明。 如果我们在XSD文件中遇到这些文件,我们是否也不应该为这些名称空间包含XSD?

例如,在此XSD文件中,我们是否应该包含定义urn:oma:xml:xdm:extensionsurn:ietf:params:xml:ns:resource-lists以及http://www.w3.org/2001/XMLSchema命名空间的XSD?

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
    targetNamespace="urn:3gpp:ns:mcpttGroupInfo:1.0"
    xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:oxe="urn:oma:xml:xdm:extensions"
    xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:import namespace="urn:oma:xml:xdm:extensions"/>
    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"/>

    <!-- XSD element and type definitions -->

</xs:schema>

3 个答案:

答案 0 :(得分:2)

http://www.w3.org/2001/XMLSchema

是一个特殊的命名空间,用于定义自动理解的模式元素,并且按照惯例(尽管没有必要)使用'xs'别名。

你的行

xmlns:xs="http://www.w3.org/2001/XMLSchema"

只是定义架构元素的默认命名空间别名。

要包含urn:oma:xml:xdm:extensionsurn:ietf:params:xml:ns:resource-lists的架构,您需要提供schemaLocation属性,例如

<xs:import namespace="urn:oma:xml:xdm:extensions" 
           schemaLocation="http://yourSchemaLocation/yourSchema.xsd"/>

N.B。 schemaLocation可以是相对的,这对我自己的模式来说可能更合适也更方便。也许

<xs:import namespace="urn:oma:xml:xdm:extensions" 
           schemaLocation="./yourSupportingSchemaLocation/yourSchema.xsd"/>

将是一个更好的例子。

答案 1 :(得分:1)

  

如果我们在XSD文件中遇到这些文件,我们是否也不应该为这些名称空间包含XSD?

如果在XSD架构文档中遇到命名空间N的命名空间声明,则会出现以下情况之一:

  1. 它是XSD名称空间和在模式中的元素上声明使用的前缀。
  2. 它是当前架构文档的目标命名空间,声明的前缀用于对目标命名空间中的类型,元素,属性等的引用。
  3. 它不是目标命名空间,用于引用元素,类型,属性等。
  4. 它不用于引用(模式声明)元素,类型,属性等,但它是模式文档本身中使用的某个元素或属性的名称空间(例如,在xsd中:注释元素,或XSD元素上的外部命名空间属性。)。
  5. 根本没有在架构文档中使用。
  6. 如果我们正在寻求收集足以验证当前模式文档中定义的元素,属性和类型的一组模式文档(或者,或多或少等效地,直接或间接引用的模式文档集,或隐式地,从当前架构文档),然后:

    1. 案例1无关紧要:XSD命名空间的架构内置于每个符合要求的XSD验证器,无需收集。
    2. 案例2要求我们收集我们当前正在阅读的架构文档。 (据推测,我们已经知道了,或者我们为什么要首先阅读它?)
    3. 在第3种情况下,命名空间有一个xsd:import,在这种情况下,当我们处理xsd:import元素时会处理它,否则就没有这样的导入,在这种情况下当前的模式文档是不符合的,并且当符合的架构处理器尝试从中构造架构时会引发错误。
    4. 在案例4中,命名空间用于当前架构文档(例如,在xsd:documentation元素中包含的HTML段落中);如果我们想验证当前模式文档中的相关元素或属性,我们将需要该命名空间的模式文档。但是没有迹象表明有问题的命名空间可以或将要在文档中用于针对此模式进行验证。可以在这些文档中使用的唯一有用的指示是xsd:import元素。
    5. 在案例5中,命名空间声明是残缺的,没有任何明显的目的。 (它可能是组织中使用的模式文档模板的一部分,因为有问题的命名空间经常用在组织的模式文档中 - 我的模式文档通常声明XHTML命名空间的前缀 - 但不用于无论出于何种原因,这个特定的模式文档。)不需要收集此命名空间的模式文档。
    6. 在您提供的示例文档中,有四个名称空间声明。一个属于案例1:

      xmlns:xs="http://www.w3.org/2001/XMLSchema"
      

      一个属于案例2:

      xmlns:mcpttgi="urn:3gpp:ns:mcpttGroupInfo:1.0"
      

      两个属于案例3(或可能是案例5),对于这些还有xsd:import指令:

      xmlns:oxe="urn:oma:xml:xdm:extensions"
      xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
      

      如果我们通过命名空间声明而不是xsd:import和xsd:include指令驱动我们的收集策略,那么这里的区别在于我们(a)将XSD架构文档的架构添加到我们的集合中,以及(b)可能搜索用于当前架构文档的目标命名空间的其他可用架构文档。 (在某些情况下,这可能是可取的;在其他情况下,我们对同一名称空间有不同的模式,收集所有这些模式将会适得其反,因为它会产生一个冗余的,可能是自相矛盾的声明集。)

答案 2 :(得分:0)

总而言之,在定义XML模式时,include标记必须具有位置属性。否则架构将无效。 虽然import和include语句使用的XSD文件可能会丢失,这可能会触发验证程序继续进行宽松验证,但应将它们视为依赖项 因为打算在XSD架构中使用它们。

由于XSD架构也是实例文档,因此它们也依赖于它们的架构文档。但是对于这种特殊情况,它们位于“http://www.w3.org/2001/XMLSchema”(XML Schema Namespace)命名空间中,该命名空间被硬编码到XML Validator中。所以没有必要提供它。

对于从自定义模式创建的“其他”实例文档(这不是我的问题的一部分,仅提及完整性),模式位置不是必需的,尽管可以明确定义。如果没有定义,可以指示XML验证器以编程方式使用某个模式 - 最后选择哪个文件取决于实现。

但它肯定必须找到一些模式来验证实例文档 - 如果有一个名称空间声明开头。 如果此架构具有一些包含和导入,则这些文件也必须可用,并且它们必须位于location属性中指定的位置。