Graph xsd依赖关系的可视化?

Graph xsd依赖关系的可视化?,graph,xsd,visualization,dependency-management,Graph,Xsd,Visualization,Dependency Management,我有一堆XSD文件,不是我自己写的。这些文件有时会相互导入: <xs:import namespace="http://www.mysite.com/xmlns/xXX-YYYY/V" schemaLocation="http://www.mysite.com/xmlns/xXX-YYYY/V/schema_A.xsd"/> 我想在不必通读所有依赖项的情况下对它们进行概述 schemaLocation指定的URI不存在,而是使用catalog.xml文件解析架构位置 有人能

我有一堆XSD文件,不是我自己写的。这些文件有时会相互导入:

<xs:import namespace="http://www.mysite.com/xmlns/xXX-YYYY/V"  schemaLocation="http://www.mysite.com/xmlns/xXX-YYYY/V/schema_A.xsd"/>

我想在不必通读所有依赖项的情况下对它们进行概述

schemaLocation指定的URI不存在,而是使用catalog.xml文件解析架构位置

有人能推荐一种工具,通过处理catalog.xml文件中给出的信息来可视化模式的依赖关系吗

谢谢
米沙要跟进我的评论

我不知道有任何工具会考虑OASIS目录文件。看一看,看看它是否支持您需要的(和您的平台)

严格地说,依赖关系图有很多问题,这就是为什么这样的问题应该用why do you want来限定

有人认为它确实显示了XSD文件之间的依赖关系;这不是真的:它可能会显示作者认为的依赖关系是什么,但这并不是处理器实际同意的。“schemaLocation”只是一个提示,处理器可以使用,也可以不使用:“may not”使用它,除非另有指示(众所周知的XSD可以通过目录项或任何其他专有的“目录”在内部缓存),或者因为处理器可能会决定在没有外部引用的情况下不需要加载外部引用(在某些情况下可能会发生这种情况)

按照显式模式位置所描述的方式构建图表肯定更容易。它只显示了作者的意图;并不意味着它是“真实的”(因为在内容中是间接提取的,这使得整个XSD集有效,而独立于集合打开的单个XSD将无效)

尝试构建一个通过目录覆盖悬空或不存在的schemaLocation的图要困难得多,因为有多种方法来构造内容和解析机制。它会有与上面相同的缺点(除了现在作者是目录文件的作者,而不是XSD的作者)


“true”依赖关系可以通过遍历已加载和编译的架构集来构建。即使如此,您仍然需要定义与可替换组件(替换组或派生类型中的元素,通过使用xsi:type属性)的依赖关系相关的条件。这更难。

看看这个工具:。 它是一个XML模式文档生成器

它不会可视化xsd依赖项,但可以处理XML目录

每个XSD文件的概述列出了从中引用的所有其他XSD文件 (即导入、包含或重新定义)。 还有一个相反的列表,列出了引用给定模式的模式

因此,您可以使用它来确定哪些XSD文件依赖于哪些XSD文件。 至少,这比读取原始XSD文件要容易

例如,以下是使用该工具生成的文档: .基本上由两个文件生成:

ditaarch.xsd
是拉动所有其他模式(总共25个)的模式驱动程序;
catalog.xml
是解析所有文件引用的xml目录。
在这些代码中指定的是那些不透明的URI。

对于工具推荐的请求超出了堆栈溢出的范围。你应该稍微重新表述它,也许是为了逃避这里的人们的愤怒……远离谋杀,如果你考虑的是-2,你已经……),而不是“工具”。也许“方法”更好。。。无论如何,我会回答为什么目录不那么容易工作。@kjhughes我不完全同意这个政策(如果它的实际目的只是为了禁止未经授权的广告)。但除此之外,它可能会切断一些非常有趣的事情(这个问题很特别)。听着,你有一些常规任务。您已在Internet上搜索,但未找到合适的解决方案。现在,你想问也许有人知道任何方法。但是你怎么能这样问呢?好吧,只需显示由
创建的XSD文件之间的依赖关系就足够了。我自己经常需要这个。比这更深入是完全不同的问题。为此,您甚至可以考虑在特定最终用户应用程序(例如金融)的级别上创建的依赖关系,这些XML模式就是为这些应用程序而创建的。所以,你是对的,它是不可能立即可视化任何可以想象的依赖关系。