通过多个 XSL 转换跟踪源元素

发布于 2024-11-01 05:51:12 字数 619 浏览 1 评论 0原文

我正在寻找有关如何在多个 XML 到 XML 转换中跟踪源元素的想法。我有 3-50MB 的非常大的策略 XML,它们在不同时间至少经过两个单独的 XSLT。 XSLT 本身有成千上万行代码。根据源 XML 的不同,输出可能会有很大不同。

示例:假设我有一个名为 COMMISSION 的源元素,它在原始源 XML 中深度为 10 个级别:

<COMMISSION>$0.00</COMMISSION>

经过两次单独的转换后,它现在被称为 B_COMMSN 两个级别,

<B_COMMSN>$0.00</B_COMMSN>

我不是原始编码器,我需要一种方法来快速查找内容B_COMMSN 的原始源元素是...而不是通过 XSLT 和所有模板进行追溯。这对我来说只是一个工具...所以代码效率不是最高优先级...XSLT 2.0 就可以了。

仅仅将所有值更改为唯一数字是不够的,因为 1) XSLT 包含数据类型比较,并且 2) 已完成查找。例如,我可能在一个元素中具有位置号 3,并且 XSLT 使用该值转到另一个节点集来查找该位置的地址。

想法???解决方案???难道这一切都是一厢情愿吗?

I'm looking for ideas on how to trace source elements throughout multiple XML to XML transformations. I have very large policy XMLs that are 3-50MB that go through at least two separate XSLTs at different times. The XSLTs themselves have thousands and thousands of lines of code. The output can be vastly different depending on the source XML.

Example: Say I have a source element called COMMISSION that is 10 levels deep in the original source XML:

<COMMISSION>$0.00</COMMISSION>

and after two separate transforms it is now called B_COMMSN two levels in

<B_COMMSN>$0.00</B_COMMSN>

I'm not the original coder and I need a way to quickly find what the original source element of B_COMMSN is...other than tracing back through the XSLTs and all the templates. This will just be a tool for me...so code efficiency isn't the highest priority...XSLT 2.0 is fine.

Simply changing all the values to unique numbers isn't sufficient because 1) the XSLTs contain data-type comparisons, and 2) Lookups are done. For instance I might have location number 3 in one element and the XSLT uses that value to go to another nodeset to look up the address for that location.

Ideas??? Solutions??? Is it all wishful thinking?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

浮云落日 2024-11-08 05:51:12

许多 IDE(例如 IIRC Oxygen 和 Stylus Studio)都会进行“回溯”——告诉您在样式表中的哪个位置生成了特定结果树节点,和/或当时源文档中的上下文是什么。您将无法通过多个样式表一路自动进行分析,但它是一个有用的调查工具。

A number of IDEs (e.g. IIRC Oxygen and Stylus Studio) do "backtracking" - telling you where in the stylesheet a particular result tree node was generated, and/or what the context in the source document was at the time. You won't be able to automate the analysis all the way back through several stylesheets, but it's a useful investigative tool.

情徒 2024-11-08 05:51:12

如果这能有所帮助的话:

一些 XSLT 1.0 调试器具有“数据断点”——在 XML 文档中的某个节点上设置断点会导致调试器在每次该节点与 < 匹配时中断。 xsl:template>

当然,这个问题的最一般情况是定义不明确且无法解决的,因为单个节点可能影响许多输出节点/项,并且特定输出节点/项可能依赖于来自不同XML文档的多个节点。

If this could help even just a bit:

Some XSLT 1.0 debuggers have "data breakpoints" -- setting a breakpoint on a certain node in an XML document causes the debugger to break every time this node has is matched by an <xsl:template> or <xsl:for-each>.

Of course, the most general case of this problem is ill-defined and unsolvable, because a single node may affect many output nodes/items, and a specific output node/item may depend on a number of nodes from different XML documents.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文