xsi:nil="true" nodes not nil when additional attributes present
petejohanson opened this issue · comments
I service I am interacting with returns nil elements along with the xsi type information, like so:
<node xsi:type="datetime" xsi:nil="true" />
Unfortunately, Nori currently converts this to:
{:'@xsi:type' => 'datetime' }
Instead of just nil
IMHO, this isn't the expected behaviour, since we can infer the type information from the WSDL, and don't need this lingering quasi-nil hash value around just for the type information.
Thoughts? I'm not sure if all attributes should be zapped when xsi:nil
is encountered, or just xsi/xmln prefixed ones.
FYI: I'm happy to submit a PR for this, but wanted some feedback on how to handle extra attributes other than xsi:type attributes before doing so.
Thanks for opening this issue @petejohanson. I believe it's safe to assume that the value is actually nil
so long as xsi:nil
is present in the element, regardless of type information.
The best I could find was some w3 docs indicating that other attributes can be present, but no value.
http://www.w3.org/TR/xmlschema-0/#Nils
If you're interested in submitting a pull request for this, I'd be more than happy to answer any questions you might have!