On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini <lorenzobertin...@gmail.com> wrote:
> 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? As far as I know, it wasn't discussed. > 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. > Actually, Xerces-C and Xerces-C++ are just the same thing (the official name being Xerces-C++ and the name of the packages Xerces-C, if I got it correctly). > 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. > It looks like the patches cannot get integrated into the master development branch before 2.4 is out (or at least branched). However, in the meantime, I think I can create a feature branch and push your patches there ( https://www.lyx.org/trac/browser/features).
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel