Disable `trim_text` in Deserializer from_reader

[woodworker]

Is there a easy way to set trim_text to false in the Deserializer::from_str when i use quick_xml::de::from_str?

quick-xml/src/de/mod.rs

Lines 160 to 167 in a4be484

	pub fn from_reader(reader: R) -> Self {
	let mut reader = Reader::from_reader(reader);
	reader
	.expand_empty_elements(true)
	.check_end_names(true)
	.trim_text(true);
	Self::new(reader)
	}

[ImJeremyHe]

Is there a way to determine whether set trim_text by looking if there is xml:space = "preserve"?
For example:

<t xml:space="preserve">Text </t>

The trailing space here should not be trimmed.

[tafia]

There are very little customization on the serde deserializer so far. I don't think there is any major blocking point, someone just needs to write it.

[Mingun]

In the coming release Deserializer::new would be public and you could create a deserializer from a Reader (but do not turn off expand_empty_elements! For now Deserializer is not prepared for that).

Processing of xml:space still waits its own PR

[naumazeredo]

In the coming release Deserializer::new would be public

Was this implemented already? Deserializer::new is public in the latest version, but it seems useless since XmlRead can't be implemented outside of quick_xml and SliceReader and IoReader can't be instantiated also. There's no way to use Deserializer::new, unless I'm missing something here.

[Mingun]

Yes, this is oversight. So, currently this is still not possible, even in master. Need to think about better API. I also would to provide an API to create a deserializer for a part of XML, so you can mix usual Reader usage with the Deserializer usage, for example, to support streaming deserialization.

[Mingun]

According to the original use case -- I do not think that simply disabling trim_text would be usable -- it seems that you'll just break deserialization of pretty-printed XMLs at all with that setting

[naumazeredo]

Yeah, that's exactly what happened. I didn't get why that option, even though internal, exists.
I've sadly moved back to serde_xml_rs since they give an option to not trim and I'm not willing to spend more time debugging xml deserialization right now. I'll be trying quick_xml in the future in case it gets more versatility

[dralley]

The trimming of spaces within elements probably ought to be separated from the trimming of spaces between elements. It should be possible (and probably the default) to ignore the latter without affecting the text contents of elements themselves.

Having an option for trimming spaces around text contents is nice of course, but not at all necessary (the user could easily do this themselves) and as this issue points out it is more difficult to do "correctly" than originally envisioned. Maybe we should eliminate this feature and just keep the "ignore spaces between XML elements" functionality?

[Mingun]

The trimming of spaces within elements probably ought to be separated from the trimming of spaces between elements.

Yes, I think, we should move in that direction. A couple of thoughts:

• need to take into account a Deserializing tag with attribute values into Map #383 problem. I think, it can be solved by introducing a method to read all content as a string regardless of the XML markup inside:

  impl Reader {
    /// For XML
    ///
    /// <outer>  <inner/>   </outer>
    ///
    /// - can be called after BytesStart("outer")
    /// - returns "  <inner/>   "
    /// - consumes BytesEnd("outer")
    fn read_as_text(&mut self, end: QName) -> Result<Cow<str>> { ... }
  }
  // or maybe better (except for a long name :( )
  impl BytesStart {
    fn read_to_end_as_text(&self, reader: &mut Reader) -> Result<Cow<str>> { ... }
  }

• we need a lookahead to decide if whitespace is significant or not (==determine the shape of the next tag -- opening/closing/self-closing/comment/PI/CData?) -- Is there any way to read an event and not consume it? #414 is related. Should we, for example, allow XML comments in whitespace-significant parts (<outer> <!----> </outer>)? If yes, that would require a potentially infinity lookahead