XML stream writer library

[Lorenzo Bertini]

Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
> A tour of some C++ libraries for XML:
> - RapidXML: mostly unmaintained since 2013, no support for namespaces 
> (except in forks: https://github.com/dwd/rapidxml 
> <https://github.com/dwd/rapidxml>)
> - Boost Property Tree: no XML parser, which limits further use (it can 
> use RapidXML though, see above)
> - libstudxml: C++ library, designed for speed, no DOM
> - libxml2: C library, designed for features and not speed (also includes 
> XPath and XSLT, DTD and XML Schema, namespaces), "mature" and barely not 
> evolving anymore
> - libxml++: depends on glibmm2
> - Xerces-C++: C++ library, designed for features and not speed (also 
> includes XPath, DTD and XML Schema, namespaces), "mature" and barely not 
> evolving anymore; no XSLT (Xalan could be used, but it only works with a 
> ancient version of Xerces; XQuilla implemented XPath 2, but is no more 
> developed since 2016)
> - Expat: C library, designed for speed, no DOM by default (provided by 
> https://github.com/kolotsey/expat-dom 
> <https://github.com/kolotsey/expat-dom>), with namespaces
> - tinyxml2: C++ library, designed for speed only (also includes XPath 
> through the unmaintained https://github.com/stanthomas/tinyxml2-ex 
> <https://github.com/stanthomas/tinyxml2-ex>, no validation, no 
> namespaces), mature and slowly evolving
> - pugixml: C++ library, designed for speed with a few features (like 
> XPath, no validation, no namespaces), mature and evolving
> - libroxml: C library, no clear design goal (includes XPath, namespaces, 
> no validation), evolving
> - Saxon-C: C/C++ wrapper of the state-of-the-art Java library, largest 
> amount of features (XPath and XSLT 3, DTD and XML Schema validation -- 
> extension for RelaxNG: http://www.cfoster.net/saxon-jing/ 
> <http://www.cfoster.net/saxon-jing/> --, namespaces), very mature, 
> really evolving (both performance and features), but it requires a JVM 
> (Excelsior is built-in, even though it's not been maintained for quite a 
> long time)
> - Qt: no, I was joking :). Qt XML is not supported anymore, it's 
> recommended to switch to QXmlStreamReader and QXmlStreamWriter (which 
> are only SAX-like). Qt XML Patterns used to have XPath, XSLT, and XML 
> Schema, but it's been deprecated a while ago (Qt 5.13 for the last 
> wake-up call, but it hasn't been touched since Qt 4, basically)
> 
> If LyX is being really serious about XML (i.e. moving as many things as 
> possible to XML technologies), Saxon is probably the way to go. 
> Otherwise, it's going to be too heavy to ship Saxon and a JVM along with 
> LyX. Instead, pugixml seems to me like a good choice: a few features 
> (XPath is the most relevant for LyX, and included in the base library, 
> no need for addons), good performance, still maintained (there is a 
> chance to have bugs fixed in a newer version, plus security 
> vulnerabilities taken care of).
Was this addressed in the virtual meeting? Also, since Xerces-C was the 
most feature full and mature after Saxon-C, I was curious as to why you 
didn't mention it.

Anyhow, I think that for a start we'd need only the most basic features 
(tag insertion, indent), as was the purpose of #12055 in the first place 
(I'm sorry to have opened this pandora's box), so maybe no harm will 
come if we start wrapping pugi.

Let me know what you think, and if this is not the time for this, as 
with LyX 2.4 coming out there might be other things that need focus.