XMP Toolkit DOM API

I notice that the XMP Toolkit SDK has a relatively new DOM API, as documented in XMPAddendumProgrammersGuide.pdf. This lets you navigate a node-based object model e.g.
```
auto registry = IDOMImplementationRegistry::GetDOMImplementationRegistry();
auto serializer = registry->GetSerializer("rdf");
auto metadata = IMetadata::CreateMetadata();
auto simpleNode = ISimpleNode::CreateSimpleNode(kXMP_NS_XMP, AdobeXMPCommon::npos, "CreatorTool", AdobeXMPCommon::npos);
if (simpleNode) {
simpleNode->SetValue("Test", AdobeXMPCommon::npos); metadata->InsertNode(simpleNode);
}
auto defaultMap = INameSpacePrefixMap::GetDefaultNameSpacePrefixMap();
auto str = serializer->Serialize(metadata, defaultMap);
auto xx = str->c_str();
std::cout << xx;
```
I don't see much docs or use online, so I'd to know more about it:
* Does anyone here use it in preference to the older XMPCore interfaces? What was your experience like?
* Why would I choose the DOM API over the older API? It seems the older API didn't have a distinct object model, so navigation there has to go through paths and enumerating tags is an all-at-once affair.
* Does the DOM API faster or use less memory over the older API?
* Does the DOM API do lazy or incremental parsing or is the entire object graph set up during the initial parse?
* Can the Adobe engineers/managers who wrote the DOM API share some of the design considerations and motivations for writing this? Will this be developed further?

Thanks, folks.

Start with XMPAddendumProgrammersGuide.pdf and the DOM API example in the issue, then review the referenced DOM interfaces such as IDOMImplementationRegistry, IMetadata, and ISimpleNode. Done would require clear documentation answering the API's use cases, trade-offs, parsing behavior, performance, and future direction.

Written by the indexing model from the issue text.