Element as abstract data type.
Element as abstract data type. It contains only expanded names, not qualified names. This reminds of James Clark notation for XML trees and expanded names, where qualified names are absent.
See the documentation of the mixed-in query API trait(s) for more details on the uniform query API offered by this class.
Namespace declarations (and undeclarations) are not considered attributes in this API, just like in the rest of yaidom.
To illustrate equality comparisons in action, consider the following example yaidom Elem
, named schemaElem1
:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://book" elementFormDefault="qualified"> <xsd:element name="book"> <xsd:complexType> <xsd:sequence> <xsd:element name="isbn" type="xsd:string" /> <xsd:element name="title" type="xsd:string" /> <xsd:element name="authors" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema>
Now consider the following equivalent yaidom Elem
, named schemaElem2
, differing only in namespace prefixes, and in
indentation:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://book" elementFormDefault="qualified"> <xs:element name="book"> <xs:complexType> <xs:sequence> <xs:element name="isbn" type="xs:string" /> <xs:element name="title" type="xs:string" /> <xs:element name="authors" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
These 2 XML trees can be considered equal, if we take indentation and namespace prefixes out of the equation. Note that namespace prefixes also occur in the "type" attributes! The following equality comparison returns true:
def replaceTypeAttributes(elem: Elem): Elem = { elem transformElemsOrSelf { e => e.plusAttributeOption(QName("type"), e.attributeAsResolvedQNameOption(EName("type")).map(_.toString)) } } resolved.Elem(replaceTypeAttributes(schemaElem1)).removeAllInterElementWhitespace == resolved.Elem(replaceTypeAttributes(schemaElem2)).removeAllInterElementWhitespace
Immutable "resolved" Node.
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 "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).
Abstract node trait hierarchy.
Abstract node trait hierarchy. It offers a common minimal API for different kinds of nodes that can be converted (without any loss of information) to resolved nodes.
This package contains element representations that can be compared for (some notion of "value") equality, unlike normal yaidom nodes. That notion of equality is simple to understand, but "naive". The user is of the API must take control over what is compared for equality.
See eu.cdevreeze.yaidom.resolved.Node for why this package is named
resolved
.The most important difference with normal
Elem
s is that qualified names do not occur, but only expanded (element and attribute) names. This reminds of James Clark notation for XML trees and expanded names, where qualified names are absent.Moreover, the only nodes in this package are element and text nodes.
Below follows a simple example query, using the uniform query API:
The query for Scala book authors would have been exactly the same if normal
Elem
s had been used instead ofresolved.Elem
s (replacingresolvedBookstoreElem
bybookstoreElem
)!