To build the additional properties set, we need to know what was consumed by the extractors to build the final object. What was NOT consumed, will go to the additional property bag.
We don't have a nice way to know what was consumed today, so we guessed it by introspecting the model built so far. This works ok for JSON, since this is simple key matching, but it doesn't work for XML:
Node with namespace are always considered unmatched
If an internal type has a "xml" annotation, the node will be unmatched
Result impact is a bloated additional property bag, with too many things.
This is complex to fix, and have little impact on usability right now, so keeping it as "enhancement" until someone really wants an additional property set that is perfect (and then needs slightly improved design for XML)
To build the additional properties set, we need to know what was consumed by the extractors to build the final object. What was NOT consumed, will go to the additional property bag.
We don't have a nice way to know what was consumed today, so we guessed it by introspecting the model built so far. This works ok for JSON, since this is simple key matching, but it doesn't work for XML:
Result impact is a bloated additional property bag, with too many things.
This is complex to fix, and have little impact on usability right now, so keeping it as "enhancement" until someone really wants an additional property set that is perfect (and then needs slightly improved design for XML)