xsi:nil="true" nodes not nil when additional attributes present

[petejohanson]

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.

[petejohanson]

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.

[tjarratt]

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!