Change the XML parser AEXML for something better about swift-toolkit HOT 7 CLOSED

Perhaps check out http://leaks.wanari.com/2016/08/24/xml-parsing-swift/ ?

from swift-toolkit.

this shows some comparison to several XML Parsers https://swift.libhunt.com/categories/675-xml

from swift-toolkit.

It will be hard to find a full featured XML parser on iOS, especially in Swift. For what I know a lot of dev tend to use NSXMLParser provided by Apple. It does the job, but it doesn't provide a very high-level API. Most of the libs out there are wrapper around NSXMLParser. Except Fuzi which is based on libxml2 (XML parser written in C from the Gnome Project). Maybe we should give it a try.

I think r2-testapp-swift/#7 should be a good place to try a new XML parser. We can replace AEXML usage in NavigationDocumentParser class without any side effects.

from swift-toolkit.

libxml2 works very well, therefore Fuzi could be a win if it's sufficiently well written.

Looking at it, it implements namespaces, which is required, and xpath methods, which can be of great use (I can show you how to use it efficiently if needed). Apart from that, few doc available. It seems to implement a DOM API only.
-> Maybe NSXMLParser is not more complex to handle for our needs...
-> what do we do with the XML parser, apart feeding objects properties with XML content?

from swift-toolkit.

I didn't find any other use of AEXML in our code. So yes, we only use it to feed objects properties.

However, NSXMLParser only provides a SAX API. It could be at first a little more complex to implement and use. My understanding is SAX is better when parsing big files, because not all the document is loaded in memory. But, do we really need this feature? Did someone already noticed performance issue?

from swift-toolkit.

You're right about SAX, this is optimized for big files and the callback-style programming is not easy to grasp: a DOM parser with XPath support would be better (or with an xml-to-object mapping, but namespace compatible).

from swift-toolkit.

For your information: the TypeScript/NodeJS implementation uses declarative XML-Object mapping based on XPath. There is no imperative/procedural parsing of XML structures in the application code, the data model is simply annotated with XPath expressions relative to their parent context (or with JSON property expressions, in the case of webpub-manifest.json, media-overlay.json etc.). This is also how the Go implementation works, by the way.

Under the hood, an external library takes care of loading DOMs and resolving XPath expressions in order to dynamically create the in-memory equivalent data model (e.g. for package.opf, chapters.smil, navdoc.html, nav.ncx, encryption.xml, etc.)

There is obviously a runtime cost when loading large XML data sets, such as many large SMIL (Media Overlays) files, or large NavDocs (TOC). I stress-tested my implementation using a massive EPUB (Math content), which allowed me to identify a significant performance issue with the Xpath processor. I fixed this problem by coding a simple processor for a custom subset of Xpath, perfectly adequate for our use-case (i.e. XML-Object mapping, basic element and attribute matching). With this optimization, the performance gain was enormous! (in terms of both CPU and memory costs, which is important with NodeJS due to the pressure on the garbage collector).

Note that the current TypeScript/NodeJS implementation does not support XML serialisation, as there is no use-case for it. There is however full support for bi-directional JSON (de)serialisation, as JSON is both an input and output data format in the marshalling logic (e.g. read license.lcpl, write webpub-manifest.json)

from swift-toolkit.