Immutable "resolved" Node. It is called "resolved" because the element trees in this package only contain resolved element and
attribute names. Qualified names (and therefore prefixes) are gone in this representation.
"Resolved" nodes can be compared for equality. This notion of equality only considers elements and text nodes.
By removing qualified names and namespace declarations from this node representation, one source of complexity for equality
comparisons is gone.
The notion of equality defined here is simple to understand, but "naive". The user of the API must take control over what is
compared for equality. Much of the "magic" in the equality relation is gone, but the API user has to work harder to compare apples to
apples, as explained below. Other "magic" remains, because the text and attribute values here are untyped.
The notion of equality remotely reminds of the standard XQuery function fn:deep-equal, but text and attribute values are untyped
in yaidom's case, among many other differences.
As mentioned above, documents, comments, processing instructions and entity references do not occur in this node hierarchy.
Moreover, text nodes do not know whether they originate from (or must be serialized as) CDATA sections or not.
There are several reasons why equality would return false for 2 elements that should be considered equal, such as:
The text and attribute values are untyped, so equality of numbers 2 and 2.0 is not detected
QNames in text or attribute values depend on in-scope namespaces for resolution
Differences in "ignorable whitespace", meant only for pretty-printing
Text that is possibly divided over several adjacent text nodes (possibly including CDATA text nodes), but should be "coalesced"
Text that is only equal after normalizing
Note that a validating parser knows the content model, so knows precisely which whitespace is "ignorable", for example, but once the parsed
XML is turned into untyped yaidom nodes, this information is lost. (Of course in principle PSVI data could be added to Elems,
indexed by "paths", but that is beyond the scope of yaidom.)
As mentioned above, QNames in text or attribute values depend on in-scope namespaces for resolution. Yet "resolved" nodes do
not keep track of in-scope namespaces, because QNames do not exist for "resolved" nodes. So, be extra careful when comparing
"resolved" elements containing QNames in text or attribute values. Either keep track of prefix bindings (scopes) outside the
"resolved" element, or convert the QNames before turning a normal Elem into a "resolved" Elem.
Class eu.cdevreeze.yaidom.resolved.Elem has some methods to mitigate the above-mentioned small differences among elements (except
for the first difference, related to untyped data).
Immutable "resolved" Node. It is called "resolved" because the element trees in this package only contain resolved element and attribute names. Qualified names (and therefore prefixes) are gone in this representation.
"Resolved" nodes can be compared for equality. This notion of equality only considers elements and text nodes. By removing qualified names and namespace declarations from this node representation, one source of complexity for equality comparisons is gone.
The notion of equality defined here is simple to understand, but "naive". The user of the API must take control over what is compared for equality. Much of the "magic" in the equality relation is gone, but the API user has to work harder to compare apples to apples, as explained below. Other "magic" remains, because the text and attribute values here are untyped.
The notion of equality remotely reminds of the standard XQuery function
fn:deep-equal, but text and attribute values are untyped in yaidom's case, among many other differences.As mentioned above, documents, comments, processing instructions and entity references do not occur in this node hierarchy. Moreover, text nodes do not know whether they originate from (or must be serialized as) CDATA sections or not.
There are several reasons why equality would return false for 2 elements that should be considered equal, such as:
Note that a validating parser knows the content model, so knows precisely which whitespace is "ignorable", for example, but once the parsed XML is turned into untyped yaidom nodes, this information is lost. (Of course in principle PSVI data could be added to
Elems, indexed by "paths", but that is beyond the scope of yaidom.)As mentioned above, QNames in text or attribute values depend on in-scope namespaces for resolution. Yet "resolved" nodes do not keep track of in-scope namespaces, because QNames do not exist for "resolved" nodes. So, be extra careful when comparing "resolved" elements containing QNames in text or attribute values. Either keep track of prefix bindings (scopes) outside the "resolved" element, or convert the QNames before turning a normal Elem into a "resolved" Elem.
Class eu.cdevreeze.yaidom.resolved.Elem has some methods to mitigate the above-mentioned small differences among elements (except for the first difference, related to untyped data).