There is an impedance mismatch between XML's scoping rules (which are top-down, from root to leaves) and "functional trees"
(which are built bottom-up, from leaves to root). In the context of the Anti-XML library, Daniel Spiewak explained this
impedance mismatch in https://github.com/djspiewak/anti-xml/issues/78. In yaidom, however, this impedance mismatch
is far less severe. Yaidom distinguishes between Node and NodeBuilder,
and Elem and ElemBuilder in particular. Elems have (fixed, resolved) Scopes,
but ElemBuilders do not. Using NodeBuilders, Scope determination is postponed. Only ElemBuilders
can have unbound prefixes, but only Elems have (resolved) scopes. Instead of a Scope, an ElemBuilder
has a Declarations.
Another reason that the above-mentioned impedance mismatch is less of a problem in practice is that typically the XML
trees (as NodeBuilders or directly as Nodes) are built in a top-down manner. The ConverterToDocuments
in package convert recursively build Elems in a top-down manner, possibly creating an Elem
instance (for each element) twice (first without children, and finally as a copy with children added).
When using NodeBuilders to create a Document, this Document typically contains no "ignorable whitespace". This may cause
the Document not to be pretty-printed when using a (default) DocumentPrinter to convert the Document
to an XML string. See also the classes in package print.
NodeBuilders are serializable. Serialized NodeBuilder instances may well be an interesting storage format for parsed XML stored
in a database. Of course, this would be a non-standard format. Moreover, as far as queries are concerned, these columns
are mere BLOBs (unless using Java Stored Procedures written in Scala).
Linear Supertypes
Serializable, Serializable, Immutable, AnyRef, Any
DSL to build
Elem
s (orDocument
s) without having to pass parentScope
s around. Example:The latter expression could also be written as follows:
There is an impedance mismatch between XML's scoping rules (which are top-down, from root to leaves) and "functional trees" (which are built bottom-up, from leaves to root). In the context of the Anti-XML library, Daniel Spiewak explained this impedance mismatch in https://github.com/djspiewak/anti-xml/issues/78. In yaidom, however, this impedance mismatch is far less severe. Yaidom distinguishes between Node and NodeBuilder, and Elem and ElemBuilder in particular.
Elem
s have (fixed, resolved)Scope
s, butElemBuilder
s do not. UsingNodeBuilder
s,Scope
determination is postponed. OnlyElemBuilder
s can have unbound prefixes, but onlyElem
s have (resolved) scopes. Instead of a Scope, anElemBuilder
has a Declarations.Another reason that the above-mentioned impedance mismatch is less of a problem in practice is that typically the XML trees (as
NodeBuilder
s or directly asNode
s) are built in a top-down manner. The ConverterToDocuments in package convert recursively buildElem
s in a top-down manner, possibly creating anElem
instance (for each element) twice (first without children, and finally as a copy with children added).When using
NodeBuilder
s to create aDocument
, thisDocument
typically contains no "ignorable whitespace". This may cause theDocument
not to be pretty-printed when using a (default) DocumentPrinter to convert theDocument
to an XML string. See also the classes in package print.NodeBuilders are serializable. Serialized NodeBuilder instances may well be an interesting storage format for parsed XML stored in a database. Of course, this would be a non-standard format. Moreover, as far as queries are concerned, these columns are mere BLOBs (unless using Java Stored Procedures written in Scala).