Github user JohannesDaniel commented on the issue:
https://github.com/apache/nifi/pull/2587
@markap14 thank you for the response.
I will simply remove that record tag validation as there are indeed many
ways to do that before the data is processed by this reader.
There is one little corner case, I need to discuss:
Assuming we have the following data:
```
<record><map_field><key1>value1</key1><key2>...
```
If the reader is used with (coerce==true), the field "map_field" can be
parsed by defining a map in the schema. The embedded key fields do not have to
be defined, its values only have to be of the defined type for the map.
If the reader is used with (coerce==false && dropUnknown==true), the reader
will parse all fields that exist in the schema ignoring its type. However, the
data above will not be parsable even if the map exists in the schema. In this
case, the reader identifies "map_field" as a field that exists in the schema,
but the reader is not aware that it is of type map. Therefore, the reader will
not parse the embedded key fields, as they don't exist in the schema. The field
"map_field" will be classified as an empty field and not added to the record.
Furthermore, even if the reader is used with (coerce==false &&
dropUnknown==true), it will be type-aware to some extent. The reader first
checks, whether fields exist in the schema. If that is the case, the reader
additionally will check whether they are of type record (or of type array
embedding records, respectively). If that is also the case, the reader will
retrieve the subschema in order to be enabled to check whether subtags of the
current tag are known.
---
