XML stream writer library

[Richard Kimberly Heck]

On 1/12/21 6:19 PM, Thibaut Cuvelier wrote:
> On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini
> <lorenzobertini97 at gmail.com <mailto:lorenzobertini97 at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20210112/5cdd140d/attachment.html>