sealed
trait
Node extends Immutable
Value Members
-
final
def
!=(arg0: AnyRef): Boolean
-
final
def
!=(arg0: Any): Boolean
-
final
def
##(): Int
-
final
def
==(arg0: AnyRef): Boolean
-
final
def
==(arg0: Any): Boolean
-
final
def
asInstanceOf[T0]: T0
-
def
clone(): AnyRef
-
final
def
eq(arg0: AnyRef): Boolean
-
def
equals(arg0: Any): Boolean
-
def
finalize(): Unit
-
final
def
getClass(): java.lang.Class[_]
-
def
hashCode(): Int
-
final
def
isInstanceOf[T0]: Boolean
-
final
def
ne(arg0: AnyRef): Boolean
-
final
def
notify(): Unit
-
final
def
notifyAll(): Unit
-
final
def
synchronized[T0](arg0: ⇒ T0): T0
-
def
toString(): String
-
final
def
wait(): Unit
-
final
def
wait(arg0: Long, arg1: Int): Unit
-
final
def
wait(arg0: Long): Unit
Inherited from Immutable
Inherited from AnyRef
Inherited from Any
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
Elem
s, indexed by "element 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 Elem has some methods to mitigate the above-mentioned small differences among elements (except for the first difference, related to untyped data).