Attributes not always included in final hash

[ArnoldMEDLINQ]

Given this simple minimal example:

<data>
  <test1 attr1="a1"/>
  <test2 attr1="a1">
    <id>myId</id>
  </test2>
  <test3 attr="a1">content</test3>
</data>

The output is:
{"data"=>{"test1"=>{"@attr1"=>"a1"}, "test2"=>{"id"=>"myId", "@attr1"=>"a1"}, "test3"=>"content"}}

The attribute of the tag test3 is missing. I believe this to be an error. Especially as many XML standards exspect this attributes to be used. E.G. the new XRechnung (en16931) declares many attributes this way. Is there a possibility to include the attributes of tags with content but without further tags inside them into the hash?

[dub357]

This has bit me as well and its happening because of how Nori handles XML elements that have 1 child which is a single text node. In this case, it creates a StringWithAttributes object which is used as the hash value. This class extends the String class, but has an accessor for the attributes hash. Because it extends String, the to_s implementation simply returns itself so the attributes dont show up in the to_s version of the hash of the root hash, but they are there.

Unfortunately, users of the gem must check each hash value to see if its an instance of Nori::StringWithAttributes in order to access those attributes. This is very frustrating if you have a large XML document.

Whats annoying about this is that nodes with absolutely no children (like 'test1' in your example) get transformed into as hash with the attributes as the hash elements as you'd expect, so its only elements with one text child that have this strange behavior. I'd like to see an option you could pass to the parser which would allow you to change this if you want. Maybe an option named something like :string_with_attributes_is_hash, which when true would return a hash with the String itself as a hash key named 'content' or something and the attributes would be merged in. Maybe I'll put in a merge request...

[dub357]

Actually looks like someone already beat me to it:

#106