我正在使用XSLT 2.0（使用SaxonHE）将一些XML Schema文档转换为一组文本文件。 假设我想为输入XSD中找到的每个xs：complexType输出一个不同的输出文件，我的模板会像下面那样轻松
-Xdump:java+system+heap+snap:events=throw+systhrow,filter=java/lang/OutOfMemoryError
对于任何包含xs：complexType的至少一个元素的XSD，我得到的输出在＆＃39; target / {$ fileName} .txt＆＃39;中正确生成。并且在此过程中不会生成其他文件。
当我使用不包含任何xs的XSD运行此转换时出现问题：complexType，处理器生成一个默认的空xml文件，其名称遵循$ {input_file} .xml其中$ {input_file}是名称输入文件。 （例如books.xsd被转换为books.xsd.xml）。 如果没有与我的转换选择的模板匹配，如何摆脱默认的xml文件？
我使用的处理器是SaxonHE9，但我和其他人的结果相同。
答案 0 :(得分：0)
Martin确定了原因：实际上XSLT 2.0规范要求至少有一个结果文档，因此如果没有创建二级结果文档，则创建主要结果，即使它是空的。这是一个非常令人费解的规则，但我认为一些WG成员认为它是XSLT 1.0兼容性所必需的。
主要结果的文件名由“基本输出URI”确定。当您从命令行处理整个目录时，每个转换的基本输出URI由输出目录的名称和输入文件名称的最后部分组成。
XSLT 3.0规范放宽了这条规则。它说（非规范性地）：
在本规范的先前版本中，有人说过 初始模板或函数的原始结果是空序列，a 当且仅当转换时，才应生成结果树 不生成二级结果（即，如果它没有调用 XSL：结果文档）。这条规定最有可能 如果转换产生序列化结果会产生明显的效果， 并将这些结果写入持久存储：效果是 然后，产生空主结果的转换将会 如果和，则覆盖基本输出URI位置的任何现有内容 只有转换不产生其他输出。处理器API 提供与早期版本的XSLT的向后兼容性必须 尊重这种行为，但没有新处理器的要求 这样做的API。
Saxon暂时采取谨慎态度保留2.0行为，但这肯定值得再次考虑。