- From: Michael Kay <mike@s...>
- To: Mukul Gandhi <mukulg@s...>
- Date: Tue, 8 Feb 2022 15:41:15 +0000
| I believe that setCoalescing() only affects the DOM created by an XML parser; it doesn't affect a DOM created programmatically.
Saxon's XPath-DOM interface attempts to provide a coalesced view of a DOM that contains multiple adjacent text nodes,inced allowing for programmatically-created DOMs.
However, I'm not 100% convinced it's worth the effort, since when you update a DOM programmatically, it's certainly possible create all kinds of garbage which Saxon won't be able to handle, such as elements with invalid names or namespaces.
Michael Kay Saxonica On 8 Feb 2022, at 15:12, Mukul Gandhi < mukulg@s...> wrote:
actually, Xerces's latest XSD 1.1 implementation for xs:assert within the 2.12.2 release doesn't have this bug, and therefore that doesn't require any fix.
On Tue, Feb 8, 2022 at 7:07 PM Mukul Gandhi < mukulg@s...> wrote: Hi Mike, On Tue, Feb 8, 2022 at 6:03 AM Michael Kay < mike@s...> wrote: In the XDM model the content of the Test element is a single text node. XDM does not allow two adjacent text nodes.
There are certainly XPath implementations, especially those running against a DOM, that get this wrong. You seem to be running against an implementation that has "cdata-section" nodes, which do not exist in XDM.
Thanks, for the clarification.
This was a bug with Apache Xerces's XPath 2.0 engine as well, that's based on DOM. We just applied the fix, as you've stated.
--
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
Cart
