<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/12/21 6:19 PM, Thibaut Cuvelier
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAK0LPyj7vSEV5ugaX6MQDtTWoRUBBkRtNiDxspjF6DugG-DyNw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">https://github.com/dwd/rapidxml</a>
<br>
> <<a href="https://github.com/dwd/rapidxml"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">https://github.com/kolotsey/expat-dom</a>
<br>
> <<a href="https://github.com/kolotsey/expat-dom"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">https://github.com/stanthomas/tinyxml2-ex</a>
<br>
> <<a href="https://github.com/stanthomas/tinyxml2-ex"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">http://www.cfoster.net/saxon-jing/</a>
<br>
> <<a href="http://www.cfoster.net/saxon-jing/"
rel="noreferrer" target="_blank" moz-do-not-send="true">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>
<p>We were pretty focused on planning for 2.4.0. <br>
</p>
<p> </p>
<blockquote type="cite"
cite="mid:CAK0LPyj7vSEV5ugaX6MQDtTWoRUBBkRtNiDxspjF6DugG-DyNw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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"
moz-do-not-send="true">https://www.lyx.org/trac/browser/features</a>).
<br>
</div>
</div>
</div>
</blockquote>
<p>Yes, that would be the way to go.</p>
<p>Riki</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>