On 1/12/21 6:19 PM, Thibaut Cuvelier wrote: > On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini > <lorenzobertin...@gmail.com <mailto: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> > > <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> > > <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> > > <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/> > > <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.
We were pretty focused on planning for 2.4.0. > 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 > <https://www.lyx.org/trac/browser/features>). Yes, that would be the way to go. Riki
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
