URIResolver、Docbook 和 XSL 转换
我正在尝试使用 Java / Xalan 以及来自 https://sourceforge.net/projects/docbook/files/docbook-xsl/1.76.1/ 以及一些本地 xsl 文件提供一些自定义和覆盖。
我想阻止我的应用程序必须下载外部资源或访问本地文件。所以我实现了一个扩展 URIResolver 接口的类。
问题在于 resolve(final String href, Final String base) 函数没有提供足够的信息来识别正在请求的特定文件。
例如，使用
随后可能会导入 http://docbook.sourceforge.net /release/xsl/current/xhtml/docbook.xsl，在这种情况下，href 参数设置为 http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook .xsl。但是，如果 docbook.xsl 导入名为 defaults.xsl 的文件，则 href 参数也会设置为 defaults.xsl，并且 base 设置为 null。
问题在于 href 和 base 参数不能唯一标识资源，并且您也无法通过观察前面的 href 的顺序来猜测正在请求哪个文件。是否有一些技巧可以准确找出正在请求文件的上下文？
I am attempting to transform some Docbook XSL to HTML using Java / Xalan and a mixture of the official Docbook XSL files from https://sourceforge.net/projects/docbook/files/docbook-xsl/1.76.1/ with some local xsl files that provide some customizations and overrides.
I want to prevent my application from having to download external resources or access local files. So I have implemented a class that extends the URIResolver interface.
The problem is that the resolve(final String href, final String base) function is not providing enough information to identify the particular file that is being requested.
For example, one of the local override files is imported from the xsl file using <xsl:import href="../../../xsl/html.xsl"/>. In this case the href parameter for my resolver class is set to ../../../xsl/html.xsl, which is fine. The html.xsl file then imports a file called defaults.xsl. The href parameter is set to only defaults.xsl, and the base parameter is set to null.
This might be followed by an import of http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl, in which case the href parameter is set to http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl. However, if the docbook.xsl imports a file called defaults.xsl, the href parameter is also set to defaults.xsl and base is set to null.
The issue is that the href and base parameters don't uniquely identify the resource, and you can't guess which file is being requested by watching the order of the previous hrefs either. Is there some trick to finding out exactly what context a file is being requested in?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您创建转换的来源是否有系统 ID？如果不是，这可能是您的 URI 解析器中的基数始终为 null 的原因。
如果您从输入流创建转换，则可以手动将系统 ID 分配给源。如果需要，您可以生成一个人工 URI，并在 URI 解析器中使用该人工 URI 来映射回基本 URI。另外，请确保您在 URI 解析器中创建的源也具有系统 ID，否则从这些文件导入的资源也会出现相同的问题。
Does the Source you are creating the transform from have a system ID? If not, this might be a reason why your base is always null in your URI resolver.
If you are creating transforms from input streams, you can manually assign a system ID to a source. You can generate an artificial one if necessary and use that artificial URI in your URI resolver to map back to a base URI. Also make sure the sources you create in your URI resolver also have system IDs or the same problem will occur with resources imported from those files.