XML Parsers

在讲 annotation processor 的实作之前，我们要先了解一般的处理方式，通常是写 XML parser 去处理这些 RSS 的 tag ，这跟我们的 processor 实作息息相关，因为 annotation processor 产生出来的程序码其实就是我们一般的 XML parser 的程序码。 一般来说，处理 RSS tag 可以直接用 XML 的 parser ，因为他跟 XML 的结构和格式相同，这篇主要会讲解如果使用纯 kotlin 的方式写 XML parser ，会有哪些选择，也会分析哪个 parser 比较符合我们的需求。

在 XML parser 中，我们可以把 XML 档案内容看成是一颗树，每个节点就是一个 tag ，而节点底下也会有他的子节点，也就是它底下包含的 tag 。

<channel>
    <title>the title</title>
    <author>the author</author>
    <description>description</description>
</channel>

以上面的 XML 为例，我们有一个 channel 的根节点，底下包含了 title 、author 和 description 三个子节点，有些 parser 是用 steam 资料流的方式载入资料，所以他们的特性就是按节点的先後顺序去取资料。

下面列出三个的 XML Parser，我们分别来分析一下他们：

• DOM
  • 把整个 XML 结构载到记忆体里，然後爬里面的资料，所以当档案很大的时候，会耗费比较多的记忆体。
  • 不是以 steam 资料流的方式载入资料，所以方便跨层寻找 tag ，不依赖节点走访的先後顺序取资料。
  • 可以对资料进行插入和删除 tag 。
• SAX
  • 内部实作是 event pushing 机制。
  • 以 steam 资料流方式载入资料，读到哪，写到哪，依赖节点走访的先後顺序。
  • 比 DOM parser 省记忆体。
  • 在 runtime 时，效率比较好。
  • 不可以对资料进行插入和删除 tag 。
• StAX
  • SAX 的兄弟版本，差别只是内部实作是 event pulling 机制。
  • 以 steam 资料流方式载入资料，读到哪，写到哪，依赖节点走访的先後顺序。
  • 比 DOM parser 省记忆体。
  • 在 runtime 时，效率也比 DOM parser 好。
  • 也无法对资料进行插入和删除 tag 。

以我们要做 RSS parser 的需求来说，我们会需要方便去跨层寻找 tag ，而且有些时候 tag 内可能会夹带一些 HTML 的 snippet ，如果要透过 SAX 或是 StAX ，势必是要写很多特例处理，不然就是要限制 RSS source 不能夹带 HTML ，但这样会降低 library 的使用弹性。虽然说 DOM parser 用比较多记忆体，但他可以为我们的实作带来一些方便，也满足我们跨层寻找 tag 的需求。另外，RSS 的单档也不会太大，所以记忆体的耗费不会是太大的问题。总结以上的观点，我认为使用 DOM parser 来作为基底 parser 是比较理想的选择。

附注：
1. Event Pushing: 使用者要跟 API 注册类似 callback 的东西去获取 event，所以使用者对於 event 的控制度较低。
2. Event Pulling: 使用者可以透过 API 主动去要 event ，要 event 的当下就 generate 那个 event ，所以使用者可以控制甚麽时候产生 event 。