On Sun, Nov 3, 2019 at 1:50 PM Nikolay Sivov nsivov@codeweavers.com wrote:
I think this looks good in principle, my suggestion would be to do a deeper cleanup first. Especially for 'empty_element' field.
Right now it's used for things that are not elements, with name suggesting otherwise. Using 'struct element' for it is also misleading for the same reason.
Much of the difficulty seems to be caused by a shortcoming in XML terminology. Obviously the XML declaration, DTD, and processing instructions are not elements. However, they are strikingly similar to an empty element both practically and visually, and the xmllite reader method MoveToElement even treats them as such. Yet, I am not aware of a concise term that encompasses these semantics.
Maybe we can keep is as is, and use strictly for empty elements, because it's used together with element stack. Then we could add another structure, without defined type for example as a part of reader struct, to hold temporary data for "current" node - strings and position.
This other structure would need to contain the same members as struct element: the same three strings, the same position, and the same list for storing attributes. And we come back to what we call this thing. "Un-nestable element-like non-element thing" seems a little unwieldy. But do we really need 2 or 3 or 4 structures and 2 or 3 or 4 instances for these when one should suffice, just because XML doesn't have a proper term for the whole set?