resolved

Type Members

1. final case class Elem(resolvedName: EName, resolvedAttributes: Map[EName, String], children: IndexedSeq[Node]) extends Node with queryapi.ClarkNodes.Elem with ClarkElemLike with UpdatableElemLike with TransformableElemLike with Product with Serializable

   

   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.from(replaceTypeAttributes(schemaElem1)).removeAllInterElementWhitespace ==
     resolved.Elem.from(replaceTypeAttributes(schemaElem2)).removeAllInterElementWhitespace

2. sealed trait Node extends queryapi.ClarkNodes.Node with Immutable

   

   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:

   • 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).

3. final case class Text(text: String) extends Node with queryapi.ClarkNodes.Text with Product with Serializable