trygvis/anti-xml — comment on commit 65b72d9b004765e13698a8876b7f8357669ded90
File: src/main/scala/com/codecommit/antixml/node.scala line 202
By djspiewak:

So in general, this is creating some weird issues with respect to incremental tree construction. Some of these issues are apparent in the code required to make the parsing work. If you instantiate XML nodes in code, you will be building the tree bottom-up. However, in order to build an `Elem`, you need namespace information from the *parents* (which you haven't built yet). So, the build process is this weird back and forth, bottom-up and top-down, depending on information.

Additionally, and maybe more significantly, this tangles scope structures with the (still-to-be-built) ancestor structure. What happens if you build an ancestry that contradicts the scope structure? What if that contradiction is shadowed by subsequent definitions so it doesn't *actually* affect the `Elem`? (e.g. declare a scope ordering of `"foo" :: "bar" :: "foo" :: "baz"` but introduce namespaces in the ancestry in order as `"foo" :: "bar" :: "baz" :: "foo"`)

Do we really need to know the full scoping and shadowing that led to the specific `NamespaceBinding` for this particular `Elem`? Why isn't a flat `Map`-like structure of the current scope sufficient?