Support document-oriented XML?

[FranklinChen]

It seems this tool merges elements at the same level rather than preserve document order, e.g.

<doc>
    <comment>A comment.</comment>
    <sentence>This is the first sentence.</sentence>
    <break/>
    <sentence>This is the second sentence.</sentence>
    <sentence>This is the third sentence.</sentence>
    <comment>Another comment.</comment>
</doc>

results in something I don't expect, where instead of <doc> being treated as a list of possible sub-elements, it's doing a reorder and merge. Will a document-oriented order ever be supported?

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
pub struct Doc {
    #[serde(rename = "$text")]
    pub text: Option<String>,
    #[serde(rename = "break")]
    pub doc_break: Break,
    pub sentence: Vec<String>,
    pub comment: Vec<String>,
}

#[derive(Serialize, Deserialize)]
pub struct Break {
}

[Thomblin]

@FranklinChen Good idea. Actually I did never test it, as it was not important to me. I preserve the order of the elements now. It is fixed in the latest version

[FranklinChen]

Oh, I see what you did in 0.6.18, that's not what actually I meant. I got

#[derive(Serialize, Deserialize)]
pub struct Doc {
    #[serde(rename = "$text")]
    pub text: Option<String>,
    pub comment: Vec<String>,
    pub sentence: Vec<String>,
    #[serde(rename = "break")]
    pub doc_break: Break,
}

#[derive(Serialize, Deserialize)]
pub struct Break {
}

but the real issue is that the XML is not document-oriented and this data type loses information and does not represent the document (think of a Markdown document represented as XML, for example). I had in mind something like

pub struct Doc {
    contents: Vec<DocContent>,
}

pub enum DocContent {
    Comment(String),
    Sentence(String),
    Break,
}

I understand, of course, if this is completely out of the scope of what your tools is intended for.

[Thomblin]

I see. So what you need is a new option that bundles all possible child elements into enums?

[FranklinChen]

Yes, if possible. There may be heuristics necessary to determine whether this is the probable intent, e.g. if there is repetition of something at the same level interspersed with other stuff.

[Thomblin]

So, a toggle to force enums whenever there are more than 1 different types of child elements?

[FranklinChen]

I think a useful heuristic is, create an enum for content inside an element if there are non-contiguous sub-elements of the same type, e.g. the following would not cause an enum because one could assume that the intention was an array of comment followed by an array of sentence.

<doc>
    <comment>A comment.</comment>
    <comment>Another comment.</comment>
    <sentence>This is the first sentence.</sentence>
    <sentence>This is the second sentence.</sentence>
    <sentence>This is the third sentence.</sentence>
</doc>

[Thomblin]

Is this a real world example? XML that I saw so far would bundle those elements as

<doc>
    <comments>
        <comment>A comment.</comment>
        <comment>Another comment.</comment>
    </comments>
    <sentences>
        <sentence>This is the first sentence.</sentence>
        <sentence>This is the second sentence.</sentence>
        <sentence>This is the third sentence.</sentence>
    </sentences>
</doc>

How about elements that contain attributes or further child elements?

[FranklinChen]

Yes, these are stylized real-life examples. I agree that bundling would be most precise, but the person who created the XML (not necessarily me) does not necessarily bundle them that way. For example, the following XML Schema would represent the (unbundled) example I gave:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
    <xs:element name="doc">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="comment" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
                <xs:element name="sentence" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

This is your tool, so you can judge what is reasonable to support, of course. There could well be attributes also and more child elements, recursively.

[Thomblin]

I understand. I try to find a solution that might be suitable for most people / use cases. I am not sure yet how that would look like