Open cdwilson opened 3 years ago
Related issue that I just bumped into, which is that although the current suggestion "works" for deserialization, it ruins the ability to cleanly round-trip via serialization, since you'll get back ns:foo
tags everywhere. :(
Little late to the party. However if I understand it correctly we can just use the #yaserde(text)
macro attribute to parse text child nodes.
#[derive(Debug, YaDeserialize)]
struct Root {
#[yaserde(attribute)]
attr: String,
#[yaserde(text)]
text: String,
}
Works for me. In my case there is no namespaces in the XML input file.
I'm trying to use yaserde (for the first time) to deserialize XML that has a default namespace like this:
Per the discussion in #92 it looks like the recommended way to handle this is to define a namespace prefix for the default namespace (
prefix = "ns"
) and then apply that namespace prefix to each field in the struct via#[yaserde(prefix = "ns")]
.However, it appears that text elements require the explicit namespace prefix, but attributes do not require it. Can you help me understand why it's not necessary to explicitly define the namespace prefix for attributes? And the reverse question: why is it necessary to explicitly define the namespace prefix for the text element if the
default_namespace
has already been defined?Here's an example where
prefix = "ns"
has been applied to thetext
element, but not to theattr
attribute and it works fine:If I remove the
prefix = "ns"
from thetext
element, I get an error"bad namespace for text, found http://example.com/ns"
.In general, it would be nice if instead of creating a fake namespace prefix that doesn't actually exist (
ns
in the example above), the default namespace could be handled implicitly, i.e. being able to just use something like this: