<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini <<a href="mailto:lorenzobertini97@gmail.com">lorenzobertini97@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:<br>
> A tour of some C++ libraries for XML:<br>
> - RapidXML: mostly unmaintained since 2013, no support for namespaces <br>
> (except in forks: <a href="https://github.com/dwd/rapidxml" rel="noreferrer" target="_blank">https://github.com/dwd/rapidxml</a> <br>
> <<a href="https://github.com/dwd/rapidxml" rel="noreferrer" target="_blank">https://github.com/dwd/rapidxml</a>>)<br>
> - Boost Property Tree: no XML parser, which limits further use (it can <br>
> use RapidXML though, see above)<br>
> - libstudxml: C++ library, designed for speed, no DOM<br>
> - libxml2: C library, designed for features and not speed (also includes <br>
> XPath and XSLT, DTD and XML Schema, namespaces), "mature" and barely not <br>
> evolving anymore<br>
> - libxml++: depends on glibmm2<br>
> - Xerces-C++: C++ library, designed for features and not speed (also <br>
> includes XPath, DTD and XML Schema, namespaces), "mature" and barely not <br>
> evolving anymore; no XSLT (Xalan could be used, but it only works with a <br>
> ancient version of Xerces; XQuilla implemented XPath 2, but is no more <br>
> developed since 2016)<br>
> - Expat: C library, designed for speed, no DOM by default (provided by <br>
> <a href="https://github.com/kolotsey/expat-dom" rel="noreferrer" target="_blank">https://github.com/kolotsey/expat-dom</a> <br>
> <<a href="https://github.com/kolotsey/expat-dom" rel="noreferrer" target="_blank">https://github.com/kolotsey/expat-dom</a>>), with namespaces<br>
> - tinyxml2: C++ library, designed for speed only (also includes XPath <br>
> through the unmaintained <a href="https://github.com/stanthomas/tinyxml2-ex" rel="noreferrer" target="_blank">https://github.com/stanthomas/tinyxml2-ex</a> <br>
> <<a href="https://github.com/stanthomas/tinyxml2-ex" rel="noreferrer" target="_blank">https://github.com/stanthomas/tinyxml2-ex</a>>, no validation, no <br>
> namespaces), mature and slowly evolving<br>
> - pugixml: C++ library, designed for speed with a few features (like <br>
> XPath, no validation, no namespaces), mature and evolving<br>
> - libroxml: C library, no clear design goal (includes XPath, namespaces, <br>
> no validation), evolving<br>
> - Saxon-C: C/C++ wrapper of the state-of-the-art Java library, largest <br>
> amount of features (XPath and XSLT 3, DTD and XML Schema validation -- <br>
> extension for RelaxNG: <a href="http://www.cfoster.net/saxon-jing/" rel="noreferrer" target="_blank">http://www.cfoster.net/saxon-jing/</a> <br>
> <<a href="http://www.cfoster.net/saxon-jing/" rel="noreferrer" target="_blank">http://www.cfoster.net/saxon-jing/</a>> --, namespaces), very mature, <br>
> really evolving (both performance and features), but it requires a JVM <br>
> (Excelsior is built-in, even though it's not been maintained for quite a <br>
> long time)<br>
> - Qt: no, I was joking :). Qt XML is not supported anymore, it's <br>
> recommended to switch to QXmlStreamReader and QXmlStreamWriter (which <br>
> are only SAX-like). Qt XML Patterns used to have XPath, XSLT, and XML <br>
> Schema, but it's been deprecated a while ago (Qt 5.13 for the last <br>
> wake-up call, but it hasn't been touched since Qt 4, basically)<br>
> <br>
> If LyX is being really serious about XML (i.e. moving as many things as <br>
> possible to XML technologies), Saxon is probably the way to go. <br>
> Otherwise, it's going to be too heavy to ship Saxon and a JVM along with <br>
> LyX. Instead, pugixml seems to me like a good choice: a few features <br>
> (XPath is the most relevant for LyX, and included in the base library, <br>
> no need for addons), good performance, still maintained (there is a <br>
> chance to have bugs fixed in a newer version, plus security <br>
> vulnerabilities taken care of).<br>
Was this addressed in the virtual meeting? </blockquote><div><br></div><div>As far as I know, it wasn't discussed. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also, since Xerces-C was the <br>
most feature full and mature after Saxon-C, I was curious as to why you <br>
didn't mention it.<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyhow, I think that for a start we'd need only the most basic features <br>
(tag insertion, indent), as was the purpose of #12055 in the first place <br>
(I'm sorry to have opened this pandora's box), so maybe no harm will <br>
come if we start wrapping pugi.<br>
<br>
Let me know what you think, and if this is not the time for this, as <br>
with LyX 2.4 coming out there might be other things that need focus.<br></blockquote><div><br></div><div>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 (<a href="https://www.lyx.org/trac/browser/features">https://www.lyx.org/trac/browser/features</a>). <br></div></div></div>