[12/27] nifi-minifi-cpp git commit: MINIFICPP-114 Consolidate JSON API use to RapidJSON

Mon, 12 Feb 2018 10:09:13 -0800 

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/faq.zh-cn.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/faq.zh-cn.md 
b/thirdparty/rapidjson-1.1.0/doc/faq.zh-cn.md
new file mode 100644
index 0000000..ed100e1
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/faq.zh-cn.md
@@ -0,0 +1,290 @@
+# 常见问题
+
+[TOC]
+
+## 一般问题
+
+1. RapidJSON 是什么？
+
+   RapidJSON 是一个 C++ 库，用于解析及生成 JSON。读者
可参考它的所有 [特点](doc/features.zh-cn.md)。
+
+2. 为什么称作 RapidJSON？
+
+   它的灵感来自于 
[RapidXML](http://rapidxml.sourceforge.net/)，RapidXML 是一个高速的 XML 
DOM 解析器。
+
+3. RapidJSON 与 RapidXML 相似么？
+
+   RapidJSON 借镜了 RapidXML 的一些设计, 包括原位（*in 
situ*）解析、只有头文件的库。但两者的 API 是完å…
¨ä¸åŒçš„。此外 RapidJSON 也提供许多 RapidXML 没有的特点。
+
+4. RapidJSON 是免费的么？
+
+   是的，它在 MIT 特許條款下å…
è´¹ã€‚它可用于商业软件。详情请参看 
[license.txt](https://github.com/miloyip/rapidjson/blob/master/license.txt)。
+
+5. RapidJSON 很小么？它有何依赖？
+
+   是的。在 Windows 上，一个解析 JSON 
并打印出统计的可执行文件少于 30KB。
+
+   RapidJSON 仅依赖于 C++ 标准库。
+
+6. 怎样安装 RapidJSON？
+
+   见 [安装一节](../readme.zh-cn.md#安装)。
+
+7. RapidJSON 能否运行于我的平台？
+
+   社区已在多个操作系统／编译器／CPU 架构的组合上测试 
RapidJSON。但我们无法确保它能运行于你
特定的平台上。只需要生成及执行单元测试便能获取答案。
+
+8. RapidJSON 支持 C++03 么？C++11 呢？
+
+   RapidJSON 开始时在 C++03 上实现。后来加入了可选的 C++11 
特性支持（如转移构造函数、`noexcept`）。RapidJSON 应该å…
¼å®¹æ‰€æœ‰éµä»Ž C++03 或 C++11 的编译器。
+
+9. RapidJSON 是否真的用于实际应用？
+
+   是的。它被é…
ç½®äºŽå‰å°åŠåŽå°çš„真实应用中。一个社区成员说 RapidJSON 
在他们的系统中每日解析 5 千万个 JSON。
+
+10. RapidJSON 是如何被测试的？
+
+   RapidJSON 包含一组单å…
ƒæµ‹è¯•åŽ»æ‰§è¡Œè‡ªåŠ¨æµ‹è¯•ã€‚[Travis](https://travis-ci.org/miloyip/rapidjson/)（供
 Linux 平台）及 
[AppVeyor](https://ci.appveyor.com/project/miloyip/rapidjson/)（供 Windows 
平台）会对所有修改进行编译及执行单元测试。在 Linux 
下还会使用 Valgrind 去检测内存泄漏。
+
+11. RapidJSON 是否有完整的文档？
+
+   RapidJSON 提供了使用手册及 API 说明文档。
+
+12. 有没有其他替代品？
+
+   有许多替代品。例如 
[nativejson-benchmark](https://github.com/miloyip/nativejson-benchmark) 
列出了一些开源的 C/C++ JSON 库。[json.org](http://www.json.org/) 
也有一个列表。
+
+## JSON
+
+1. 什么是 JSON？
+
+   JSON (JavaScript Object Notation) 是一个轻量的数据交换æ 
¼å¼ã€‚它使用人类可读的文本格式。更多关于 JSON 的细节可考 
[RFC7159](http://www.ietf.org/rfc/rfc7159.txt) 及 
[ECMA-404](http://www.ecma-international.org/publications/standards/Ecma-404.htm)。
+
+2. JSON 有什么应用场合？
+
+   JSON 常用于网页应用程序，以传
送结构化数据。它也可作为文件格式用于数据持久化。
+
+2. RapidJSON 是否符合 JSON 标准？
+
+   是。RapidJSON 完全符合 [RFC7159](http://www.ietf.org/rfc/rfc7159.txt) 
及 
[ECMA-404](http://www.ecma-international.org/publications/standards/Ecma-404.htm)。它能处理一些特殊æƒ
…况，例如支持 JSON 字符串中含有空字符及代理对（surrogate 
pair）。
+
+3. RapidJSON 是否支持宽松的语法？
+
+   现时不支持。RapidJSON 只支持严格的标准æ 
¼å¼ã€‚宽松语法现时在这 
[issue](https://github.com/miloyip/rapidjson/issues/36) 中进行讨论。
+
+## DOM 与 SAX
+
+1. 什么是 DOM 风格 API？
+
+   Document Object Model（DOM）是一个储存于内存的 JSON 
表示方式，用于查询及修改 JSON。
+
+2. 什么是 SAX 风格 API?
+
+   SAX 是一个事件驱动的 API，用于解析及生成 JSON。
+
+3. 我应用 DOM 还是 SAX？
+
+   DOM 易于查询及修改。SAX 则是非常快及省内
存的，但通常较难使用。
+
+4. 什么是原位（*in situ*）解析？
+
+   原位解析会把 JSON 字符串直接解码至输入的 JSON 
中。这是一个优化，可减少内存消耗及提升性能，但输入的 
JSON 会被更改。进一步细节请参考 [原位解析](doc/dom.zh-cn.md) 
。
+
+5. 什么时候会产生解析错误？
+
+   当输入的 JSON 包含非法语法，或不能表示一个值（如 
Number 
太大），或解析器的处理器中断解析过程，解析器都会产生一个错误。详æƒ
…请参考 [解析错误](doc/dom.zh-cn.md)。
+
+6. 有什么错误信息？
+
+   错误信息存储在 `ParseResult`，它包
含错误代号及偏移值（从 JSON 
开始至错误处的字符数目）。可以把错误代号翻译为人类可读的错误讯息。
+
+7. 为何不只使用 `double` 去表示 JSON number？
+
+   一些应用需要使用 64 位无号／有号整数。这些整数不能无
损地转换成 `double`。因此解析器会检测一个 JSON number 
是否能转换至各种整数类型及 `double`。
+
+8. 如何清空并最小化 `document` 或 `value` 的容量？
+
+   调用 `SetXXX()` 方法 - 
这些方法会调用析构函数，并重建空的 Object 或 Array:
+
+   ~~~~~~~~~~cpp
+   Document d;
+   ...
+   d.SetObject();  // clear and minimize
+   ~~~~~~~~~~
+
+   另外，也可以参考在 [C++ swap with temporary 
idiom](https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Clear-and-minimize) 
中的一种等价的方法:
+   ~~~~~~~~~~cpp
+   Value(kObjectType).Swap(d);
+   ~~~~~~~~~~
+   或者，使用这个稍微长一点的代码也能完成同样的事情:
+   ~~~~~~~~~~cpp
+   d.Swap(Value(kObjectType).Move()); 
+   ~~~~~~~~~~
+
+9. 如何将一个 `document` 节点插入到另一个 `document` 中？
+
+   比如有以下两个 document(DOM):
+   ~~~~~~~~~~cpp
+   Document person;
+   
person.Parse("{\"person\":{\"name\":{\"first\":\"Adam\",\"last\":\"Thomas\"}}}");
+   
+   Document address;
+   address.Parse("{\"address\":{\"city\":\"Moscow\",\"street\":\"Quiet\"}}");
+   ~~~~~~~~~~
+   假设我们希望将整个 `address` 插入到 `person` 中，作为å…
¶çš„一个子节点:
+   ~~~~~~~~~~js
+   { "person": {
+      "name": { "first": "Adam", "last": "Thomas" },
+      "address": { "city": "Moscow", "street": "Quiet" }
+      }
+   }
+   ~~~~~~~~~~
+
+   在插入节点的过程中需要注意 `document` 和 `value` 
的生命周期并且正确地使用 allocator 进行内存分配和管理。
+
+   一个简单有效的方法就是修改上述 `address` 
变量的定义，让其使用 `person` 的 allocator 初始化，然后将å…
¶æ·»åŠ åˆ°æ ¹èŠ‚点。
+
+   ~~~~~~~~~~cpp
+   Documnet address(person.GetAllocator());
+   ...
+   person["person"].AddMember("address", address["address"], 
person.GetAllocator());
+   ~~~~~~~~~~
+   当然，如果你不想通过显式地写出 `address` 的 key 来得到å…
¶å€¼ï¼Œå¯ä»¥ä½¿ç”¨è¿­ä»£å™¨æ¥å®žçŽ°:
+   ~~~~~~~~~~cpp
+   auto addressRoot = address.MemberBegin();
+   person["person"].AddMember(addressRoot->name, addressRoot->value, 
person.GetAllocator());
+   ~~~~~~~~~~
+   
+   此外，还可以通过深拷贝 address document 来实现:
+   ~~~~~~~~~~cpp
+   Value addressValue = Value(address["address"], person.GetAllocator());
+   person["person"].AddMember("address", addressValue, person.GetAllocator());
+   ~~~~~~~~~~
+
+## Document/Value (DOM)
+
+1. 什么是转移语意？为什么？
+
+   `Value` 
不用复制语意，而使用了转移语意。这是指，当把来源值赋值于目æ
 ‡å€¼æ—¶ï¼Œæ¥æºå€¼çš„所有权会转移至目标值。
+
+   由于转移快于复制，此设计决定强迫使用者
注意到复制的消耗。
+
+2. 怎样去复制一个值？
+
+   有两个 API 可用：含 allocator 的构造函数，以及 
`CopyFrom()`。可参考 [深复制 Value](doc/tutorial.zh-cn.md) 
里的用例。
+
+3. 为什么我需要提供字符串的长度？
+
+   由于 C 字符串是空字符结尾的，需要使用 `strlen()` 
去计算其长度，这是线性复杂度的操作。若使用者
已知字符串的长度，对很多操作来说会造成不必要的消耗。
+
+   此外，RapidJSON 可处理含有 
`\u0000`（空字符）的字符串。若一个字符串含有空字符，`strlen()`
 便不能返回真正的字符串长度。在这种情况下使用者必
须明确地提供字符串长度。
+
+4. 为什么在许多 DOM 操作 API 中要提供分配器作为参数？
+
+   由于这些 API 是 `Value` 的成员函数，我们不希望为每个 
`Value` 储存一个分配器指针。
+
+5. 它会转换各种数值类型么？
+
+   当使用 `GetInt()`、`GetUint()` 等 API 
时，可能会发生转换。对于整数至整数转换，仅
当保证转换安å…
¨æ‰ä¼šè½¬æ¢ï¼ˆå¦åˆ™ä¼šæ–­è¨€å¤±è´¥ï¼‰ã€‚然而，当把一个 64 
位有号／无号整数转换至 double 
时，它会转换，但有可能会损失精度。含有小数的数字、或大于
 64 位的整数，都只能使用 `GetDouble()` 获取其值。
+
+## Reader/Writer (SAX)
+
+1. 为什么不仅仅用 `printf` 输出一个 JSON？为什么需要 
`Writer`？
+
+   最重要的是，`Writer` 能确保输出的 JSON 是æ 
¼å¼æ­£ç¡®çš„。错误地调用 SAX 事件（如 `StartObject()` 错配 
`EndArray()`）会造成断言失败。此外，`Writer` 
会把字符串进行转义（如 `\n`）。最后，`printf()` 
的数值输出可能并不是一个合法的 JSON number，特别是某些 
locale 会有数字分隔符。而且 `Writer` 
的数值字符串转换是使用非常快的算法来实现的，胜过 
`printf()` 及 `iostream`。
+
+2. 我能否暂停解析过程，并在稍后继续？
+
+   
基于性能考虑，目前版本并不直接支持此功能。然而，若执行环境支持多线程，使用è€
…可以在另一线程解析 JSON，并通过阻塞输入流去暂停。
+
+## Unicode
+
+1. 它是否支持 UTF-8、UTF-16 及其他格式？
+
+   是。它完全支持 
UTF-8、UTF-16（大端／小端）、UTF-32（大端／小端）及 ASCII。
+
+2. 它能否检测编码的合法性？
+
+   能。只需把 `kParseValidateEncodingFlag` 参考传给 
`Parse()`。若发现在输入流中有非法的编码，它就会产生 
`kParseErrorStringInvalidEncoding` 错误。
+
+3. 什么是代理对（surrogate pair)？RapidJSON 是否支持？
+
+   JSON 使用 UTF-16 编码去转义 Unicode 字符，例如 `\u5927` 
表示中文字“大”。要处理基本多文种平面（basic multilingual 
plane，BMP）以外的字符时，UTF-16 会把那些字符编码成两个 16 
位值，这称为 UTF-16 代理对。例如，绘文字字符 U+1F602 在 JSON 
中可被编码成 `\uD83D\uDE02`。
+
+   RapidJSON 完全支持解析及生成 UTF-16 代理对。 
+
+4. 它能否处理 JSON 字符串中的 `\u0000`（空字符）？
+
+   能。RapidJSON 完全支持 JSON 
字符串中的空字符。然而，使用者
需要注意到这件事，并使用 `GetStringLength()` 及相关 API 
去取得字符串真正长度。
+
+5. 能否对所有非 ASCII 字符输出成 `\uxxxx` 形式？
+
+   可以。只要在 `Writer` 中使用 `ASCII<>` 作为输出编ç 
å‚数，就可以强逼转义那些字符。
+
+## 流
+
+1. 我有一个很大的 JSON 文件。我应否把它整个载入内存中？
+
+   使用者可使用 `FileReadStream` 去逐块读å…
¥æ–‡ä»¶ã€‚但若使用于原位解析，必须载入整个文件。
+
+2. 我能否解析一个从网络上串流进来的 JSON？
+
+   可以。使用者可根据 `FileReadStream` 
的实现，去实现一个自定义的流。
+
+3. 我不知道一些 JSON 将会使用哪种编码。怎样处理它们？
+
+   你可以使用 `AutoUTFInputStream`，它能自动检测输入流的编ç 
ã€‚然而，它会带来一些性能开销。
+
+4. 什么是 BOM？RapidJSON 怎样处理它？
+
+   [字节顺序标记（byte order mark, 
BOM）](http://en.wikipedia.org/wiki/Byte_order_mark) 
有时会出现于文件／流的开始，以表示其 UTF 编码类型。
+
+   RapidJSON 的 `EncodedInputStream` 可检测／跳过 
BOM。`EncodedOutputStream` 可选择是否写入 BOM。可参考 [编ç 
æµ](doc/stream.zh-cn.md) 中的例子。
+
+5. 为什么会涉及大端／小端？
+
+   流的大端／小端是 UTF-16 及 UTF-32 流要处理的问题，而 
UTF-8 不需要处理。
+
+## 性能
+
+1. RapidJSON 是否真的快？
+
+   是。它可能是最快的开源 JSON 库。有一个 
[评测](https://github.com/miloyip/nativejson-benchmark) 评估 C/C++ JSON 
库的性能。
+
+2. 为什么它会快？
+
+   RapidJSON 
的许多设计是针对时间／空间性能来设计的，这些决定可能会影响
 API 的易用性。此外，它也使用了许多底层优化（内
部函数／intrinsic、SIMD）及特别的算法（自定义的 double 
至字符串转换、字符串至 double 的转换）。
+
+3. 什是是 SIMD？它如何用于 RapidJSON？
+
+   [SIMD](http://en.wikipedia.org/wiki/SIMD) 指令可以在现代 CPU 
中执行并行运算。RapidJSON 支持了 Intel 的 SSE2/SSE4.2 去加
速跳过空白字符。在解析含缩进的 JSON 
时，这能提升性能。只要定义名为 `RAPIDJSON_SSE2` 或 
`RAPIDJSON_SSE42` 
的宏，就能启动这个功能。然而，若在不支持这些指令集的机器上执行这些可执行文件，会导致崩溃。
+
+4. 它会消耗许多内存么？
+
+   RapidJSON 的设计目标是减低内存占用。
+
+   在 SAX API 中，`Reader` 消耗的内存与 JSON 树深度加上最长 
JSON 字符成正比。
+
+   在 DOM API 中，每个 `Value` 在 32/64 位架构下分别消耗 16/24 
字节。RapidJSON 也使用一个特殊的内存分配器去减少分é…
çš„额外开销。
+
+5. 高性能的意义何在？
+
+   有些应用程序需要处理非常大的 JSON 
文件。而有些后台应用程序需要处理大量的 
JSON。达到高性能同时改善延时及吞吐量。更广义来说，这也可以节省能源。
+
+## 八挂
+
+1. 谁是 RapidJSON 的开发者？
+
+   叶劲峰（Milo Yip，[miloyip](https://github.com/miloyip)）是 
RapidJSON 的原作者。全世界许多贡献者一直在改善 
RapidJSON。Philipp A. 
Hartmann（[pah](https://github.com/pah)）实现了许多改进，也设置了自动化测试，而且还参与许多社区讨论。丁欧南（Don
 
Ding，[thebusytypist](https://github.com/thebusytypist)）实现了迭代式解析器。Andrii
 Senkovych（[jollyroger](https://github.com/jollyroger)）完成了向 CMake 
的迁移。Kosta（[Kosta-Github](https://github.com/Kosta-Github)）提供了一个非常灵巧的短字符串优化。也需要感谢å
…¶ä»–献者及社区成员。
+
+2. 为何你要开发 RapidJSON？
+
+   在 2011 年开始这项目是，它仅一个兴趣项目。Milo Yip 
是一个游戏程序员，他在那时候认识到 JSON 
并希望在未来的项目中使用。由于 JSON 
好像很简单，他希望写一个仅有头文件并且快速的程序库。
+
+3. 为什么开发中段有一段长期空档？
+
+   主要是个人因素，例如加入新家庭成员。另外，Milo Yip 
也花了许多业馀时间去翻译 Jason Gregory 的《Game Engine 
Architecture》至中文版《游戏引擎架构》。
+
+4. 为什么这个项目从 Google Code 搬到 GitHub？
+
+   这是大势所趋，而且 GitHub 更为强大及方便。

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/features.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/features.md 
b/thirdparty/rapidjson-1.1.0/doc/features.md
new file mode 100644
index 0000000..732fb21
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/features.md
@@ -0,0 +1,104 @@
+# Features
+
+## General
+
+* Cross-platform
+ * Compilers: Visual Studio, gcc, clang, etc.
+ * Architectures: x86, x64, ARM, etc.
+ * Operating systems: Windows, Mac OS X, Linux, iOS, Android, etc.
+* Easy installation
+ * Header files only library. Just copy the headers to your project.
+* Self-contained, minimal dependences
+ * No STL, BOOST, etc.
+ * Only included `<cstdio>`, `<cstdlib>`, `<cstring>`, `<inttypes.h>`, 
`<new>`, `<stdint.h>`. 
+* Without C++ exception, RTTI
+* High performance
+ * Use template and inline functions to reduce function call overheads.
+ * Internal optimized Grisu2 and floating point parsing implementations.
+ * Optional SSE2/SSE4.2 support.
+
+## Standard compliance
+
+* RapidJSON should be fully RFC4627/ECMA-404 compliance.
+* Support JSON Pointer (RFC6901).
+* Support JSON Schema Draft v4.
+* Support Unicode surrogate.
+* Support null character (`"\u0000"`)
+ * For example, `["Hello\u0000World"]` can be parsed and handled gracefully. 
There is API for getting/setting lengths of string.
+* Support optional relaxed syntax.
+ * Single line (`// ...`) and multiple line (`/* ... */`) comments 
(`kParseCommentsFlag`). 
+ * Trailing commas at the end of objects and arrays 
(`kParseTrailingCommasFlag`).
+ * `NaN`, `Inf`, `Infinity`, `-Inf` and `-Infinity` as `double` values 
(`kParseNanAndInfFlag`)
+* [NPM compliant](http://github.com/miloyip/rapidjson/blob/master/doc/npm.md).
+
+## Unicode
+
+* Support UTF-8, UTF-16, UTF-32 encodings, including little endian and big 
endian.
+ * These encodings are used in input/output streams and in-memory 
representation.
+* Support automatic detection of encodings in input stream.
+* Support transcoding between encodings internally.
+ * For example, you can read a UTF-8 file and let RapidJSON transcode the JSON 
strings into UTF-16 in the DOM.
+* Support encoding validation internally.
+ * For example, you can read a UTF-8 file, and let RapidJSON check whether all 
JSON strings are valid UTF-8 byte sequence.
+* Support custom character types.
+ * By default the character types are `char` for UTF8, `wchar_t` for UTF16, 
`uint32_t` for UTF32.
+* Support custom encodings.
+
+## API styles
+
+* SAX (Simple API for XML) style API
+ * Similar to [SAX](http://en.wikipedia.org/wiki/Simple_API_for_XML), 
RapidJSON provides a event sequential access parser API 
(`rapidjson::GenericReader`). It also provides a generator API 
(`rapidjson::Writer`) which consumes the same set of events.
+* DOM (Document Object Model) style API
+ * Similar to [DOM](http://en.wikipedia.org/wiki/Document_Object_Model) for 
HTML/XML, RapidJSON can parse JSON into a DOM representation 
(`rapidjson::GenericDocument`), for easy manipulation, and finally stringify 
back to JSON if needed.
+ * The DOM style API (`rapidjson::GenericDocument`) is actually implemented 
with SAX style API (`rapidjson::GenericReader`). SAX is faster but sometimes 
DOM is easier. Users can pick their choices according to scenarios.
+
+## Parsing
+
+* Recursive (default) and iterative parser
+ * Recursive parser is faster but prone to stack overflow in extreme cases.
+ * Iterative parser use custom stack to keep parsing state.
+* Support *in situ* parsing.
+ * Parse JSON string values in-place at the source JSON, and then the DOM 
points to addresses of those strings.
+ * Faster than convention parsing: no allocation for strings, no copy (if 
string does not contain escapes), cache-friendly.
+* Support 32-bit/64-bit signed/unsigned integer and `double` for JSON number 
type.
+* Support parsing multiple JSONs in input stream (`kParseStopWhenDoneFlag`).
+* Error Handling
+ * Support comprehensive error code if parsing failed.
+ * Support error message localization.
+
+## DOM (Document)
+
+* RapidJSON checks range of numerical values for conversions.
+* Optimization for string literal
+ * Only store pointer instead of copying
+* Optimization for "short" strings
+ * Store short string in `Value` internally without additional allocation.
+ * For UTF-8 string: maximum 11 characters in 32-bit, 21 characters in 64-bit 
(13 characters in x86-64).
+* Optionally support `std::string` (define `RAPIDJSON_HAS_STDSTRING=1`)
+
+## Generation
+
+* Support `rapidjson::PrettyWriter` for adding newlines and indentations.
+
+## Stream
+
+* Support `rapidjson::GenericStringBuffer` for storing the output JSON as 
string.
+* Support `rapidjson::FileReadStream` and `rapidjson::FileWriteStream` for 
input/output `FILE` object.
+* Support custom streams.
+
+## Memory
+
+* Minimize memory overheads for DOM.
+ * Each JSON value occupies exactly 16/20 bytes for most 32/64-bit machines 
(excluding text string).
+* Support fast default allocator.
+ * A stack-based allocator (allocate sequentially, prohibit to free individual 
allocations, suitable for parsing).
+ * User can provide a pre-allocated buffer. (Possible to parse a number of 
JSONs without any CRT allocation)
+* Support standard CRT(C-runtime) allocator.
+* Support custom allocators.
+
+## Miscellaneous
+
+* Some C++11 support (optional)
+ * Rvalue reference
+ * `noexcept` specifier
+ * Range-based for loop

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/features.zh-cn.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/features.zh-cn.md 
b/thirdparty/rapidjson-1.1.0/doc/features.zh-cn.md
new file mode 100644
index 0000000..fd3fd4d
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/features.zh-cn.md
@@ -0,0 +1,103 @@
+# 特点
+
+## 总体
+
+* 跨平台
+ * 编译器：Visual Studio、gcc、clang 等
+ * 架构：x86、x64、ARM 等
+ * 操作系统：Windows、Mac OS X、Linux、iOS、Android 等
+* 容易安装
+ * 只有头文件的库。只需把头文件复制至你的项目中。
+* 独立、最小依赖
+ * 不需依赖 STL、BOOST 等。
+ * 只包含 `<cstdio>`, `<cstdlib>`, `<cstring>`, `<inttypes.h>`, `<new>`, 
`<stdint.h>`。 
+* 没使用 C++ 异常、RTTI
+* 高性能
+ * 使用模版及内联函数去降低函数调用开销。
+ * 内部经优化的 Grisu2 及浮点数解析实现。
+ * 可选的 SSE2/SSE4.2 支持。
+
+## 符合标准
+
+* RapidJSON 应完全符合 RFC4627/ECMA-404 标准。
+* 支持 JSON Pointer (RFC6901).
+* 支持 JSON Schema Draft v4.
+* 支持 Unicod 代理对（surrogate pair）。
+* 支持空字符（`"\u0000"`）。
+ * 例如，可以优雅地解析及处理 
`["Hello\u0000World"]`。含读写字符串长度的 API。
+* 支持可选的放宽语法
+ * 单行（`// ...`）及多行（`/* ... */`） 注释 
(`kParseCommentsFlag`)。
+ * 在对象和数组结束前含逗号 (`kParseTrailingCommasFlag`)。
+ * `NaN`、`Inf`、`Infinity`、`-Inf` 及 `-Infinity` 作为 `double` 值 
(`kParseNanAndInfFlag`)
+* [NPM 兼容](https://github.com/miloyip/rapidjson/blob/master/doc/npm.md).
+
+## Unicode
+
+* 支持 UTF-8、UTF-16、UTF-32 编码，包括小端序和大端序。
+ * 这些编码用于输入输出流，以及内存中的表示。
+* 支持从输入流自动检测编码。
+* 内部支持编码的转换。
+ * 例如，你可以读取一个 UTF-8 文件，让 RapidJSON 把 JSON 
字符串转换至 UTF-16 的 DOM。
+* 内部支持编码校验。
+ * 例如，你可以读取一个 UTF-8 文件，让 RapidJSON 
检查是否所有 JSON 字符串是合法的 UTF-8 字节序列。
+* 支持自定义的字符类型。
+ * 预设的字符类型是：UTF-8 为 `char`，UTF-16 为 `wchar_t`，UTF32 
为 `uint32_t`。
+* 支持自定义的编码。
+
+## API 风格
+
+* SAX（Simple API for XML）风格 API
+ * 类似于 [SAX](http://en.wikipedia.org/wiki/Simple_API_for_XML), RapidJSON 
提供一个事件循序访问的解析器 
API（`rapidjson::GenericReader`）。RapidJSON 也提供一个生成器 
API（`rapidjson::Writer`），可以处理相同的事件集合。
+* DOM（Document Object Model）风格 API
+ * 类似于 HTML／XML 的 
[DOM](http://en.wikipedia.org/wiki/Document_Object_Model)，RapidJSON 可把 
JSON 解析至一个 DOM 
表示方式（`rapidjson::GenericDocument`），以方便操作。如有需要，可把
 DOM 转换（stringify）回 JSON。
+ * DOM 风格 API（`rapidjson::GenericDocument`）实际上是由 SAX 风格 
API（`rapidjson::GenericReader`）实现的。SAX 更快，但有时 DOM 
更易用。用户可根据情况作出选择。
+
+## 解析
+
+* 递归式（预设）及迭代式解析器
+ * 递归式解析器较快，但在极端情况下可出现堆栈溢出。
+ * 迭代式解析器使用自定义的堆栈去维持解析状态。
+* 支持原位（*in situ*）解析。
+ * 把 JSON 字符串的值解析至原 JSON 之中，然后让 DOM 
指向那些字符串。
+ * 比常规分析更快：不需字符串的内存分é…
ã€ä¸éœ€å¤åˆ¶ï¼ˆå¦‚字符串不含转义符）、缓存友好。
+* 对于 JSON 数字类型，支持 32-bit/64-bit 的有号／无
号整数，以及 `double`。
+* 错误处理
+ * 支持详尽的解析错误代号。
+ * 支持本地化错误信息。
+
+## DOM (Document)
+
+* RapidJSON 在类型转换时会检查数值的范围。
+* 字符串字面量的优化
+ * 只储存指针，不作复制
+* 优化“短”字符串
+ * 在 `Value` 内储存短字符串，无需额外分配。
+ * 对 UTF-8 字符串来说，32 位架构下可存储最多 11 字符，64 
位下 21 字符（x86-64 下 13 字符）。
+* 可选地支持 `std::string`（定义 `RAPIDJSON_HAS_STDSTRING=1`）
+
+## 生成
+
+* 支持 `rapidjson::PrettyWriter` 去加入换行及缩进。
+
+## 输入输出流
+
+* 支持 `rapidjson::GenericStringBuffer`，把输出的 JSON 
储存于字符串内。
+* 支持 `rapidjson::FileReadStream` 及 `rapidjson::FileWriteStream`，使用 
`FILE` 对象作输入输出。
+* 支持自定义输入输出流。
+
+## 内存
+
+* 最小化 DOM 的内存开销。
+ * 对大部分 32／64 位机器而言，每个 JSON 值只占 16 或 20 
字节（不包含字符串）。
+* 支持快速的预设分配器。
+ * 它是一个堆栈形式的分配器（顺序分é…
ï¼Œä¸å®¹è®¸å•ç‹¬é‡Šæ”¾ï¼Œé€‚合解析过程之用）。
+ * 使用者也可提供一个预分配的缓冲区。（有可能达至无需 
CRT 分配就能解析多个 JSON）
+* 支持标准 CRT（C-runtime）分配器。
+* 支持自定义分配器。
+
+## 其他
+
+* 一些 C++11 的支持（可选）
+ * 右值引用（rvalue reference）
+ * `noexcept` 修饰符
+ * 范围 for 循环

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/internals.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/internals.md 
b/thirdparty/rapidjson-1.1.0/doc/internals.md
new file mode 100644
index 0000000..49802a0
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/internals.md
@@ -0,0 +1,365 @@
+# Internals
+
+This section records some design and implementation details.
+
+[TOC]
+
+# Architecture {#Architecture}
+
+## SAX and DOM
+
+The basic relationships of SAX and DOM is shown in the following UML diagram.
+
+![Architecture UML class diagram](diagram/architecture.png)
+
+The core of the relationship is the `Handler` concept. From the SAX side, 
`Reader` parses a JSON from a stream and publish events to a `Handler`. 
`Writer` implements the `Handler` concept to handle the same set of events. 
From the DOM side, `Document` implements the `Handler` concept to build a DOM 
according to the events. `Value` supports a `Value::Accept(Handler&)` function, 
which traverses the DOM to publish events.
+
+With this design, SAX is not dependent on DOM. Even `Reader` and `Writer` have 
no dependencies between them. This provides flexibility to chain event 
publisher and handlers. Besides, `Value` does not depends on SAX as well. So, 
in addition to stringify a DOM to JSON, user may also stringify it to a XML 
writer, or do anything else.
+
+## Utility Classes
+
+Both SAX and DOM APIs depends on 3 additional concepts: `Allocator`, 
`Encoding` and `Stream`. Their inheritance hierarchy is shown as below.
+
+![Utility classes UML class diagram](diagram/utilityclass.png)
+
+# Value {#Value}
+
+`Value` (actually a typedef of `GenericValue<UTF8<>>`) is the core of DOM API. 
This section describes the design of it.
+
+## Data Layout {#DataLayout}
+
+`Value` is a [variant type](http://en.wikipedia.org/wiki/Variant_type). In 
RapidJSON's context, an instance of `Value` can contain 1 of 6 JSON value 
types. This is possible by using `union`. Each `Value` contains two members: 
`union Data data_` and a`unsigned flags_`. The `flags_` indiciates the JSON 
type, and also additional information. 
+
+The following tables show the data layout of each type. The 32-bit/64-bit 
columns indicates the size of the field in bytes.
+
+| Null              |                                  |32-bit|64-bit|
+|-------------------|----------------------------------|:----:|:----:|
+| (unused)          |                                  |4     |8     | 
+| (unused)          |                                  |4     |4     |
+| (unused)          |                                  |4     |4     |
+| `unsigned flags_` | `kNullType kNullFlag`            |4     |4     |
+
+| Bool              |                                                    
|32-bit|64-bit|
+|-------------------|----------------------------------------------------|:----:|:----:|
+| (unused)          |                                                    |4    
 |8     | 
+| (unused)          |                                                    |4    
 |4     |
+| (unused)          |                                                    |4    
 |4     |
+| `unsigned flags_` | `kBoolType` (either `kTrueFlag` or `kFalseFlag`) |4     
|4     |
+
+| String              |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `Ch* str`           | Pointer to the string (may own)     |4     |8     | 
+| `SizeType length`   | Length of string                    |4     |4     |
+| (unused)            |                                     |4     |4     |
+| `unsigned flags_`   | `kStringType kStringFlag ...`       |4     |4     |
+
+| Object              |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `Member* members`   | Pointer to array of members (owned) |4     |8     | 
+| `SizeType size`     | Number of members                   |4     |4     |
+| `SizeType capacity` | Capacity of members                 |4     |4     |
+| `unsigned flags_`   | `kObjectType kObjectFlag`           |4     |4     |
+
+| Array               |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `Value* values`     | Pointer to array of values (owned)  |4     |8     | 
+| `SizeType size`     | Number of values                    |4     |4     |
+| `SizeType capacity` | Capacity of values                  |4     |4     |
+| `unsigned flags_`   | `kArrayType kArrayFlag`             |4     |4     |
+
+| Number (Int)        |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `int i`             | 32-bit signed integer               |4     |4     | 
+| (zero padding)      | 0                                   |4     |4     |
+| (unused)            |                                     |4     |8     |
+| `unsigned flags_`   | `kNumberType kNumberFlag kIntFlag kInt64Flag ...` |4   
  |4     |
+
+| Number (UInt)       |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `unsigned u`        | 32-bit unsigned integer             |4     |4     | 
+| (zero padding)      | 0                                   |4     |4     |
+| (unused)            |                                     |4     |8     |
+| `unsigned flags_`   | `kNumberType kNumberFlag kUIntFlag kUInt64Flag ...` |4 
    |4     |
+
+| Number (Int64)      |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `int64_t i64`       | 64-bit signed integer               |8     |8     | 
+| (unused)            |                                     |4     |8     |
+| `unsigned flags_`   | `kNumberType kNumberFlag kInt64Flag ...`          |4   
  |4     |
+
+| Number (Uint64)     |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `uint64_t i64`      | 64-bit unsigned integer             |8     |8     | 
+| (unused)            |                                     |4     |8     |
+| `unsigned flags_`   | `kNumberType kNumberFlag kInt64Flag ...`          |4   
  |4     |
+
+| Number (Double)     |                                     |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `uint64_t i64`      | Double precision floating-point     |8     |8     | 
+| (unused)            |                                     |4     |8     |
+| `unsigned flags_`   | `kNumberType kNumberFlag kDoubleFlag` |4     |4     |
+
+Here are some notes:
+* To reduce memory consumption for 64-bit architecture, `SizeType` is typedef 
as `unsigned` instead of `size_t`.
+* Zero padding for 32-bit number may be placed after or before the actual 
type, according to the endianess. This makes possible for interpreting a 32-bit 
integer as a 64-bit integer, without any conversion.
+* An `Int` is always an `Int64`, but the converse is not always true.
+
+## Flags {#Flags}
+
+The 32-bit `flags_` contains both JSON type and other additional information. 
As shown in the above tables, each JSON type contains redundant `kXXXType` and 
`kXXXFlag`. This design is for optimizing the operation of testing bit-flags 
(`IsNumber()`) and obtaining a sequential number for each type (`GetType()`).
+
+String has two optional flags. `kCopyFlag` means that the string owns a copy 
of the string. `kInlineStrFlag` means using [Short-String 
Optimization](#ShortString).
+
+Number is a bit more complicated. For normal integer values, it can contains 
`kIntFlag`, `kUintFlag`,  `kInt64Flag` and/or `kUint64Flag`, according to the 
range of the integer. For numbers with fraction, and integers larger than 
64-bit range, they will be stored as `double` with `kDoubleFlag`.
+
+## Short-String Optimization {#ShortString}
+
+ [Kosta](https://github.com/Kosta-Github) provided a very neat short-string 
optimization. The optimization idea is given as follow. Excluding the `flags_`, 
a `Value` has 12 or 16 bytes (32-bit or 64-bit) for storing actual data. 
Instead of storing a pointer to a string, it is possible to store short strings 
in these space internally. For encoding with 1-byte character type (e.g. 
`char`), it can store maximum 11 or 15 characters string inside the `Value` 
type.
+
+| ShortString (Ch=char) |                                   |32-bit|64-bit|
+|---------------------|-------------------------------------|:----:|:----:|
+| `Ch str[MaxChars]`  | String buffer                       |11    |15    | 
+| `Ch invLength`      | MaxChars - Length                   |1     |1     |
+| `unsigned flags_`   | `kStringType kStringFlag ...`       |4     |4     |
+
+A special technique is applied. Instead of storing the length of string 
directly, it stores (MaxChars - length). This make it possible to store 11 
characters with trailing `\0`.
+
+This optimization can reduce memory usage for copy-string. It can also improve 
cache-coherence thus improve runtime performance.
+
+# Allocator {#InternalAllocator}
+
+`Allocator` is a concept in RapidJSON:
+~~~cpp
+concept Allocator {
+    static const bool kNeedFree;    //!< Whether this allocator needs to call 
Free().
+
+    // Allocate a memory block.
+    // \param size of the memory block in bytes.
+    // \returns pointer to the memory block.
+    void* Malloc(size_t size);
+
+    // Resize a memory block.
+    // \param originalPtr The pointer to current memory block. Null pointer is 
permitted.
+    // \param originalSize The current size in bytes. (Design issue: since 
some allocator may not book-keep this, explicitly pass to it can save memory.)
+    // \param newSize the new size in bytes.
+    void* Realloc(void* originalPtr, size_t originalSize, size_t newSize);
+
+    // Free a memory block.
+    // \param pointer to the memory block. Null pointer is permitted.
+    static void Free(void *ptr);
+};
+~~~
+
+Note that `Malloc()` and `Realloc()` are member functions but `Free()` is 
static member function.
+
+## MemoryPoolAllocator {#MemoryPoolAllocator}
+
+`MemoryPoolAllocator` is the default allocator for DOM. It allocate but do not 
free memory. This is suitable for building a DOM tree.
+
+Internally, it allocates chunks of memory from the base allocator (by default 
`CrtAllocator`) and stores the chunks as a singly linked list. When user 
requests an allocation, it allocates memory from the following order:
+
+1. User supplied buffer if it is available. (See [User Buffer section in 
DOM](doc/dom.md))
+2. If user supplied buffer is full, use the current memory chunk.
+3. If the current block is full, allocate a new block of memory.
+
+# Parsing Optimization {#ParsingOptimization}
+
+## Skip Whitespaces with SIMD {#SkipwhitespaceWithSIMD}
+
+When parsing JSON from a stream, the parser need to skip 4 whitespace 
characters:
+
+1. Space (`U+0020`)
+2. Character Tabulation (`U+000B`)
+3. Line Feed (`U+000A`)
+4. Carriage Return (`U+000D`)
+
+A simple implementation will be simply:
+~~~cpp
+void SkipWhitespace(InputStream& s) {
+    while (s.Peek() == ' ' || s.Peek() == '\n' || s.Peek() == '\r' || s.Peek() 
== '\t')
+        s.Take();
+}
+~~~
+
+However, this requires 4 comparisons and a few branching for each character. 
This was found to be a hot spot.
+
+To accelerate this process, SIMD was applied to compare 16 characters with 4 
white spaces for each iteration. Currently RapidJSON only supports SSE2 and 
SSE4.2 instructions for this. And it is only activated for UTF-8 memory 
streams, including string stream or *in situ* parsing. 
+
+To enable this optimization, need to define `RAPIDJSON_SSE2` or 
`RAPIDJSON_SSE42` before including `rapidjson.h`. Some compilers can detect the 
setting, as in `perftest.h`:
+
+~~~cpp
+// __SSE2__ and __SSE4_2__ are recognized by gcc, clang, and the Intel 
compiler.
+// We use -march=native with gmake to enable -msse2 and -msse4.2, if supported.
+#if defined(__SSE4_2__)
+#  define RAPIDJSON_SSE42
+#elif defined(__SSE2__)
+#  define RAPIDJSON_SSE2
+#endif
+~~~
+
+Note that, these are compile-time settings. Running the executable on a 
machine without such instruction set support will make it crash.
+
+### Page boundary issue
+
+In an early version of RapidJSON, [an 
issue](https://code.google.com/archive/p/rapidjson/issues/104) reported that 
the `SkipWhitespace_SIMD()` causes crash very rarely (around 1 in 500,000). 
After investigation, it is suspected that `_mm_loadu_si128()` accessed bytes 
after `'\0'`, and across a protected page boundary.
+
+In [Intel® 64 and IA-32 Architectures Optimization Reference Manual
+](http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html),
 section 10.2.1:
+
+> To support algorithms requiring unaligned 128-bit SIMD memory accesses, 
memory buffer allocation by a caller function should consider adding some pad 
space so that a callee function can safely use the address pointer safely with 
unaligned 128-bit SIMD memory operations.
+> The minimal padding size should be the width of the SIMD register that might 
be used in conjunction with unaligned SIMD memory access.
+
+This is not feasible as RapidJSON should not enforce such requirement.
+
+To fix this issue, currently the routine process bytes up to the next aligned 
address. After tha, use aligned read to perform SIMD processing. Also see 
[#85](https://github.com/miloyip/rapidjson/issues/85).
+
+## Local Stream Copy {#LocalStreamCopy}
+
+During optimization, it is found that some compilers cannot localize some 
member data access of streams into local variables or registers. Experimental 
results show that for some stream types, making a copy of the stream and used 
it in inner-loop can improve performance. For example, the actual (non-SIMD) 
implementation of `SkipWhitespace()` is implemented as:
+
+~~~cpp
+template<typename InputStream>
+void SkipWhitespace(InputStream& is) {
+    internal::StreamLocalCopy<InputStream> copy(is);
+    InputStream& s(copy.s);
+
+    while (s.Peek() == ' ' || s.Peek() == '\n' || s.Peek() == '\r' || s.Peek() 
== '\t')
+        s.Take();
+}
+~~~
+
+Depending on the traits of stream, `StreamLocalCopy` will make (or not make) a 
copy of the stream object, use it locally and copy the states of stream back to 
the original stream.
+
+## Parsing to Double {#ParsingDouble}
+
+Parsing string into `double` is difficult. The standard library function 
`strtod()` can do the job but it is slow. By default, the parsers use normal 
precision setting. This has has maximum 3 
[ULP](http://en.wikipedia.org/wiki/Unit_in_the_last_place) error and 
implemented in `internal::StrtodNormalPrecision()`.
+
+When using `kParseFullPrecisionFlag`, the parsers calls 
`internal::StrtodFullPrecision()` instead, and this function actually 
implemented 3 versions of conversion methods.
+1. 
[Fast-Path](http://www.exploringbinary.com/fast-path-decimal-to-floating-point-conversion/).
+2. Custom DIY-FP implementation as in 
[double-conversion](https://github.com/floitsch/double-conversion).
+3. Big Integer Method as in (Clinger, William D. How to read floating point 
numbers accurately. Vol. 25. No. 6. ACM, 1990).
+
+If the first conversion methods fail, it will try the second, and so on.
+
+# Generation Optimization {#GenerationOptimization}
+
+## Integer-to-String conversion {#itoa}
+
+The naive algorithm for integer-to-string conversion involves division per 
each decimal digit. We have implemented various implementations and evaluated 
them in [itoa-benchmark](https://github.com/miloyip/itoa-benchmark).
+
+Although SSE2 version is the fastest but the difference is minor by comparing 
to the first running-up `branchlut`. And `branchlut` is pure C++ implementation 
so we adopt `branchlut` in RapidJSON.
+
+## Double-to-String conversion {#dtoa}
+
+Originally RapidJSON uses `snprintf(..., ..., "%g")`  to achieve 
double-to-string conversion. This is not accurate as the default precision is 
6. Later we also find that this is slow and there is an alternative.
+
+Google's V8 [double-conversion](https://github.com/floitsch/double-conversion
+) implemented a newer, fast algorithm called Grisu3 (Loitsch, Florian. 
"Printing floating-point numbers quickly and accurately with integers." ACM 
Sigplan Notices 45.6 (2010): 233-243.).
+
+However, since it is not header-only so that we implemented a header-only 
version of Grisu2. This algorithm guarantees that the result is always 
accurate. And in most of cases it produces the shortest (optimal) string 
representation.
+
+The header-only conversion function has been evaluated in 
[dtoa-benchmark](https://github.com/miloyip/dtoa-benchmark).
+
+# Parser {#Parser}
+
+## Iterative Parser {#IterativeParser}
+
+The iterative parser is a recursive descent LL(1) parser
+implemented in a non-recursive manner.
+
+### Grammar {#IterativeParserGrammar}
+
+The grammar used for this parser is based on strict JSON syntax:
+~~~~~~~~~~
+S -> array | object
+array -> [ values ]
+object -> { members }
+values -> non-empty-values | ε
+non-empty-values -> value addition-values
+addition-values -> ε | , non-empty-values
+members -> non-empty-members | ε
+non-empty-members -> member addition-members
+addition-members -> ε | , non-empty-members
+member -> STRING : value
+value -> STRING | NUMBER | NULL | BOOLEAN | object | array
+~~~~~~~~~~
+
+Note that left factoring is applied to non-terminals `values` and `members`
+to make the grammar be LL(1).
+
+### Parsing Table {#IterativeParserParsingTable}
+
+Based on the grammar, we can construct the FIRST and FOLLOW set.
+
+The FIRST set of non-terminals is listed below:
+
+|    NON-TERMINAL   |               FIRST              |
+|:-----------------:|:--------------------------------:|
+|       array       |                 [                |
+|       object      |                 {                |
+|       values      | ε STRING NUMBER NULL BOOLEAN { [ |
+|  addition-values  |              ε COMMA             |
+|      members      |             ε STRING             |
+|  addition-members |              ε COMMA             |
+|       member      |              STRING              |
+|       value       |  STRING NUMBER NULL BOOLEAN { [  |
+|         S         |                [ {               |
+| non-empty-members |              STRING              |
+|  non-empty-values |  STRING NUMBER NULL BOOLEAN { [  |
+
+The FOLLOW set is listed below:
+
+|    NON-TERMINAL   |  FOLLOW |
+|:-----------------:|:-------:|
+|         S         |    $    |
+|       array       | , $ } ] |
+|       object      | , $ } ] |
+|       values      |    ]    |
+|  non-empty-values |    ]    |
+|  addition-values  |    ]    |
+|      members      |    }    |
+| non-empty-members |    }    |
+|  addition-members |    }    |
+|       member      |   , }   |
+|       value       |  , } ]  |
+
+Finally the parsing table can be constructed from FIRST and FOLLOW set:
+
+|    NON-TERMINAL   |           [           |           {           |          
,          | : | ] | } |          STRING         |         NUMBER        |      
    NULL         |        BOOLEAN        |
+|:-----------------:|:---------------------:|:---------------------:|:-------------------:|:-:|:-:|:-:|:-----------------------:|:---------------------:|:---------------------:|:---------------------:|
+|         S         |         array         |         object        |          
           |   |   |   |                         |                       |      
                 |                       |
+|       array       |       [ values ]      |                       |          
           |   |   |   |                         |                       |      
                 |                       |
+|       object      |                       |      { members }      |          
           |   |   |   |                         |                       |      
                 |                       |
+|       values      |    non-empty-values   |    non-empty-values   |          
           |   | ε |   |     non-empty-values    |    non-empty-values   |    
non-empty-values   |    non-empty-values   |
+|  non-empty-values | value addition-values | value addition-values |          
           |   |   |   |  value addition-values  | value addition-values | 
value addition-values | value addition-values |
+|  addition-values  |                       |                       |  , 
non-empty-values |   | ε |   |                         |                       
|                       |                       |
+|      members      |                       |                       |          
           |   |   | ε |    non-empty-members    |                       |     
                  |                       |
+| non-empty-members |                       |                       |          
           |   |   |   | member addition-members |                       |      
                 |                       |
+|  addition-members |                       |                       | , 
non-empty-members |   |   | ε |                         |                      
 |                       |                       |
+|       member      |                       |                       |          
           |   |   |   |      STRING : value     |                       |      
                 |                       |
+|       value       |         array         |         object        |          
           |   |   |   |          STRING         |         NUMBER        |      
    NULL         |        BOOLEAN        |
+
+There is a great 
[tool](http://hackingoff.com/compilers/predict-first-follow-set) for above 
grammar analysis.
+
+### Implementation {#IterativeParserImplementation}
+
+Based on the parsing table, a direct(or conventional) implementation
+that pushes the production body in reverse order
+while generating a production could work.
+
+In RapidJSON, several modifications(or adaptations to current design) are made 
to a direct implementation.
+
+First, the parsing table is encoded in a state machine in RapidJSON.
+States are constructed by the head and body of production.
+State transitions are constructed by production rules.
+Besides, extra states are added for productions involved with `array` and 
`object`.
+In this way the generation of array values or object members would be a single 
state transition,
+rather than several pop/push operations in the direct implementation.
+This also makes the estimation of stack size more easier.
+
+The state diagram is shown as follows:
+
+![State Diagram](diagram/iterative-parser-states-diagram.png)
+
+Second, the iterative parser also keeps track of array's value count and 
object's member count
+in its internal stack, which may be different from a conventional 
implementation.

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.png
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.png 
b/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.png
new file mode 100644
index 0000000..b3b2f80
Binary files /dev/null and b/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.png 
differ

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.svg
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.svg 
b/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.svg
new file mode 100644
index 0000000..9708d5a
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/logo/rapidjson.svg
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/";
+   xmlns:cc="http://creativecommons.org/ns#";
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
+   xmlns:svg="http://www.w3.org/2000/svg";
+   xmlns="http://www.w3.org/2000/svg";
+   xmlns:xlink="http://www.w3.org/1999/xlink";
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd";
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape";
+   width="217.15039"
+   height="60.831055"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="rapidjson.svg">
+  <defs
+     id="defs4">
+    <linearGradient
+       id="linearGradient3801">
+      <stop
+         style="stop-color:#000000;stop-opacity:1;"
+         offset="0"
+         id="stop3803" />
+      <stop
+         style="stop-color:#000000;stop-opacity:0;"
+         offset="1"
+         id="stop3805" />
+    </linearGradient>
+    <linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient3801"
+       id="linearGradient3807"
+       x1="81.25"
+       y1="52.737183"
+       x2="122.25"
+       y2="52.737183"
+       gradientUnits="userSpaceOnUse"
+       
gradientTransform="matrix(1.2378503,0,0,1.1662045,-226.99279,64.427324)" />
+    <linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient3801"
+       id="linearGradient3935"
+       gradientUnits="userSpaceOnUse"
+       gradientTransform="matrix(-1.4768835,0,0,2.2904698,246.48785,81.630301)"
+       x1="81.25"
+       y1="52.737183"
+       x2="115.96579"
+       y2="48.439766" />
+    <linearGradient
+       inkscape:collect="always"
+       xlink:href="#linearGradient3801"
+       id="linearGradient3947"
+       gradientUnits="userSpaceOnUse"
+       
gradientTransform="matrix(1.2378503,0,0,1.1662045,-226.99279,-10.072676)"
+       x1="81.25"
+       y1="52.737183"
+       x2="122.25"
+       y2="52.737183" />
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="2"
+     inkscape:cx="207.8959"
+     inkscape:cy="-3.2283687"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1920"
+     inkscape:window-height="1137"
+     inkscape:window-x="-8"
+     inkscape:window-y="-8"
+     inkscape:window-maximized="1"
+     fit-margin-top="10"
+     fit-margin-left="10"
+     fit-margin-right="10"
+     fit-margin-bottom="10" />
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage"; />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-39.132812,-38.772339)">
+    <text
+       sodipodi:linespacing="125%"
+       id="text3939"
+       y="79.862183"
+       x="147.5"
+       
style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Microsoft
 JhengHei;-inkscape-font-specification:Microsoft JhengHei"
+       xml:space="preserve"><tspan
+         
style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Inconsolata;-inkscape-font-specification:Inconsolata"
+         y="79.862183"
+         x="147.5"
+         id="tspan3941"
+         sodipodi:role="line"><tspan
+           id="tspan3943"
+           
style="font-size:42px;font-style:oblique;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;writing-mode:lr-tb;text-anchor:middle;font-family:Segoe
 UI;-inkscape-font-specification:Segoe UI Oblique">Rapid</tspan><tspan
+           id="tspan3945"
+           style="font-weight:bold;-inkscape-font-specification:Inconsolata 
Bold">JSON</tspan></tspan></text>
+  </g>
+</svg>

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/misc/DoxygenLayout.xml
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/misc/DoxygenLayout.xml 
b/thirdparty/rapidjson-1.1.0/doc/misc/DoxygenLayout.xml
new file mode 100644
index 0000000..b7c9586
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/misc/DoxygenLayout.xml
@@ -0,0 +1,194 @@
+<doxygenlayout version="1.0">
+  <!-- Generated by doxygen 1.8.7 -->
+  <!-- Navigation index tabs for HTML output -->
+  <navindex>
+    <tab type="mainpage" visible="yes" title=""/>
+    <tab type="pages" visible="yes" title="" intro=""/>
+    <tab type="modules" visible="yes" title="" intro=""/>
+    <tab type="namespaces" visible="yes" title="">
+      <tab type="namespacelist" visible="yes" title="" intro=""/>
+      <tab type="namespacemembers" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="classes" visible="yes" title="">
+      <tab type="classlist" visible="yes" title="" intro=""/>
+      <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/> 
+      <tab type="hierarchy" visible="yes" title="" intro=""/>
+      <tab type="classmembers" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="files" visible="yes" title="">
+      <tab type="filelist" visible="yes" title="" intro=""/>
+      <tab type="globals" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="examples" visible="yes" title="" intro=""/>  
+  </navindex>
+
+  <!-- Layout definition for a class page -->
+  <class>
+    <briefdescription visible="yes"/>
+    <includes visible="$SHOW_INCLUDE_FILES"/>
+    <inheritancegraph visible="$CLASS_GRAPH"/>
+    <collaborationgraph visible="$COLLABORATION_GRAPH"/>
+    <memberdecl>
+      <nestedclasses visible="yes" title=""/>
+      <publictypes title=""/>
+      <services title=""/>
+      <interfaces title=""/>
+      <publicslots title=""/>
+      <signals title=""/>
+      <publicmethods title=""/>
+      <publicstaticmethods title=""/>
+      <publicattributes title=""/>
+      <publicstaticattributes title=""/>
+      <protectedtypes title=""/>
+      <protectedslots title=""/>
+      <protectedmethods title=""/>
+      <protectedstaticmethods title=""/>
+      <protectedattributes title=""/>
+      <protectedstaticattributes title=""/>
+      <packagetypes title=""/>
+      <packagemethods title=""/>
+      <packagestaticmethods title=""/>
+      <packageattributes title=""/>
+      <packagestaticattributes title=""/>
+      <properties title=""/>
+      <events title=""/>
+      <privatetypes title=""/>
+      <privateslots title=""/>
+      <privatemethods title=""/>
+      <privatestaticmethods title=""/>
+      <privateattributes title=""/>
+      <privatestaticattributes title=""/>
+      <friends title=""/>
+      <related title="" subtitle=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <services title=""/>
+      <interfaces title=""/>
+      <constructors title=""/>
+      <functions title=""/>
+      <related title=""/>
+      <variables title=""/>
+      <properties title=""/>
+      <events title=""/>
+    </memberdef>
+    <allmemberslink visible="yes"/>
+    <usedfiles visible="$SHOW_USED_FILES"/>
+    <authorsection visible="yes"/>
+  </class>
+
+  <!-- Layout definition for a namespace page -->
+  <namespace>
+    <briefdescription visible="yes"/>
+    <memberdecl>
+      <nestednamespaces visible="yes" title=""/>
+      <constantgroups visible="yes" title=""/>
+      <classes visible="yes" title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+    </memberdef>
+    <authorsection visible="yes"/>
+  </namespace>
+
+  <!-- Layout definition for a file page -->
+  <file>
+    <briefdescription visible="yes"/>
+    <includes visible="$SHOW_INCLUDE_FILES"/>
+    <includegraph visible="$INCLUDE_GRAPH"/>
+    <includedbygraph visible="$INCLUDED_BY_GRAPH"/>
+    <sourcelink visible="yes"/>
+    <memberdecl>
+      <classes visible="yes" title=""/>
+      <namespaces visible="yes" title=""/>
+      <constantgroups visible="yes" title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+    </memberdef>
+    <authorsection/>
+  </file>
+
+  <!-- Layout definition for a group page -->
+  <group>
+    <briefdescription visible="yes"/>
+    <groupgraph visible="$GROUP_GRAPHS"/>
+    <memberdecl>
+      <nestedgroups visible="yes" title=""/>
+      <dirs visible="yes" title=""/>
+      <files visible="yes" title=""/>
+      <namespaces visible="yes" title=""/>
+      <classes visible="yes" title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <enumvalues title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <signals title=""/>
+      <publicslots title=""/>
+      <protectedslots title=""/>
+      <privateslots title=""/>
+      <events title=""/>
+      <properties title=""/>
+      <friends title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <pagedocs/>
+      <inlineclasses title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <enumvalues title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <signals title=""/>
+      <publicslots title=""/>
+      <protectedslots title=""/>
+      <privateslots title=""/>
+      <events title=""/>
+      <properties title=""/>
+      <friends title=""/>
+    </memberdef>
+    <authorsection visible="yes"/>
+  </group>
+
+  <!-- Layout definition for a directory page -->
+  <directory>
+    <briefdescription visible="yes"/>
+    <directorygraph visible="yes"/>
+    <memberdecl>
+      <dirs visible="yes"/>
+      <files visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+  </directory>
+</doxygenlayout>

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/misc/doxygenextra.css
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/misc/doxygenextra.css 
b/thirdparty/rapidjson-1.1.0/doc/misc/doxygenextra.css
new file mode 100644
index 0000000..bd67375
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/misc/doxygenextra.css
@@ -0,0 +1,274 @@
+body code {
+       margin: 0;
+       border: 1px solid #ddd;
+       background-color: #f8f8f8;
+       border-radius: 3px;
+       padding: 0;
+}
+
+a {
+       color: #4183c4;
+}
+
+a.el {
+       font-weight: normal;
+}
+
+body, table, div, p, dl {
+       color: #333333;
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       font-size: 15px;
+       font-style: normal;
+       font-variant: normal;
+       font-weight: normal;
+       line-height: 25.5px;
+}
+
+body {
+       background-color: #eee;
+}
+
+div.header {
+       background-image: none;
+       background-color: white;
+       margin: 0px;
+       border: 0px;
+}
+
+div.headertitle {
+       width: 858px;
+       margin: 30px;
+       padding: 0px;
+}
+
+div.toc {
+       background-color: #f8f8f8;
+       border-color: #ddd;
+       margin-right: 10px;
+       margin-left: 20px;
+}
+div.toc h3 {
+       color: #333333;
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       font-size: 18px;
+       font-style: normal;
+       font-variant: normal;
+       font-weight: normal;
+}
+div.toc li {
+       color: #333333;
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       font-size: 12px;
+       font-style: normal;
+       font-variant: normal;
+       font-weight: normal;
+}
+
+.title {
+       font-size: 2.5em;
+       line-height: 63.75px;
+       border-bottom: 1px solid #ddd;
+       margin-bottom: 15px;
+       margin-left: 0px;
+       margin-right: 0px;
+       margin-top: 0px;
+}
+
+.summary {
+       float: none !important;
+       width: auto !important;
+       padding-top: 10px;
+       padding-right: 10px !important;
+}
+
+.summary + .headertitle .title {
+       font-size: 1.5em;
+       line-height: 2.0em;
+}
+
+body h1 {
+       font-size: 2em;
+       line-height: 1.7;
+       border-bottom: 1px solid #eee;
+       margin: 1em 0 15px;
+       padding: 0;
+       overflow: hidden;
+}
+
+body h2 {
+       font-size: 1.5em;
+       line-height: 1.7;
+       margin: 1em 0 15px;
+       padding: 0;
+}
+
+pre.fragment {
+       font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace;
+       font-size: 13px;
+       font-style: normal;
+       font-variant: normal;
+       font-weight: normal;
+       line-height: 19px;
+}
+
+table.doxtable th {
+       background-color: #f8f8f8;
+       color: #333333;
+       font-size: 15px;
+}
+
+table.doxtable td, table.doxtable th {
+       border: 1px solid #ddd;
+}
+
+#doc-content {
+       background-color: #fff;
+       width: 918px;
+       height: auto !important;
+       margin-left: 270px !important;
+}
+
+div.contents {
+       width: 858px;
+       margin: 30px;
+}
+
+div.line {
+       font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace;
+       font-size: 13px;
+       font-style: normal;
+       font-variant: normal;
+       font-weight: normal;
+       line-height: 19px;      
+}
+
+tt, code, pre {
+       font-family: Consolas, "Liberation Mono", Menlo, Courier, monospace;
+       font-size: 12px;
+}
+
+div.fragment {
+       background-color: #f8f8f8;
+       border: 1px solid #ddd;
+       font-size: 13px;
+       line-height: 19px;
+       overflow: auto;
+       padding: 6px 10px;
+       border-radius: 3px;
+}
+
+#topbanner {
+       position: fixed;
+       margin: 15px;
+       z-index: 101;
+}
+
+#projectname
+{
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       font-size: 38px;
+       font-weight: bold;
+       line-height: 63.75px;
+       margin: 0px;
+       padding: 2px 0px;
+}
+    
+#projectbrief
+{
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       font-size: 16px;
+       line-height: 22.4px;
+       margin: 0px 0px 13px 0px;
+       padding: 2px;
+}
+
+/* side bar and search */
+
+#side-nav
+{
+       padding: 10px 0px 20px 20px;
+       border-top: 60px solid #2980b9;
+       background-color: #343131;
+       width: 250px !important;
+       height: 100% !important;
+       position: fixed;
+}
+
+#nav-tree
+{
+       background-color: transparent;
+       background-image: none;
+       height: 100% !important;
+}
+
+#nav-tree .label
+{
+       font-family: Helvetica, arial, freesans, clean, sans-serif, 'Segoe UI 
Emoji', 'Segoe UI Symbol';
+       line-height: 25.5px;    
+       font-size: 15px;
+}
+
+#nav-tree
+{
+       color: #b3b3b3;
+}
+
+#nav-tree .selected {
+       background-image: none;
+}
+
+#nav-tree a
+{
+       color: #b3b3b3;
+}
+
+#github
+{
+       position: fixed;
+       left: auto;
+       right: auto;
+       width: 250px;
+}
+
+#MSearchBox
+{
+       margin: 20px;
+       left: 40px;
+       right: auto;
+       position: fixed;
+       width: 180px;
+}
+
+#MSearchField
+{
+       width: 121px;
+}
+
+#MSearchResultsWindow
+{
+       left: 45px !important;
+}
+
+#nav-sync
+{
+       display: none;
+}
+
+.ui-resizable .ui-resizable-handle
+{
+       width: 0px;
+}
+
+#nav-path
+{
+       display: none;
+}
+
+/* external link icon */
+div.contents a[href ^= "http"]:after {
+     content: " " 
url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAAVklEQVR4Xn3PgQkAMQhDUXfqTu7kTtkpd5RA8AInfArtQ2iRXFWT2QedAfttj2FsPIOE1eCOlEuoWWjgzYaB/IkeGOrxXhqB+uA9Bfcm0lAZuh+YIeAD+cAqSz4kCMUAAAAASUVORK5CYII=);
+}
+
+.githublogo {
+       content: 
url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyRpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNS1jMDIxIDc5LjE1NDkxMSwgMjAxMy8xMC8yOS0xMTo0NzoxNiAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9InhtcC5kaWQ6RERCMUIwOUY4NkNFMTFFM0FBNTJFRTMzNTJEMUJDNDYiIHhtcE1NOkluc3RhbmNlSUQ9InhtcC5paWQ6RERCMUIwOUU4NkNFMTFFM0FBNTJFRTMzNTJEMUJDNDYiIHhtcDpDcmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNiAoTWFjaW50b3NoKSI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5jZUlEPSJ4bXAua
 
WlkOkU1MTc4QTJBOTlBMDExRTI5QTE1QkMxMDQ2QTg5MDREIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOkU1MTc4QTJCOTlBMDExRTI5QTE1QkMxMDQ2QTg5MDREIi8+IDwvcmRmOkRlc2NyaXB0aW9uPiA8L3JkZjpSREY+IDwveDp4bXBtZXRhPiA8P3hwYWNrZXQgZW5kPSJyIj8+jUqS1wAAApVJREFUeNq0l89rE1EQx3e3gVJoSPzZeNEWPKgHoa0HBak0iHiy/4C3WvDmoZ56qJ7txVsPQu8qlqqHIhRKJZceesmhioQEfxTEtsoSpdJg1u/ABJ7Pmc1m8zLwgWTmzcw3L+/te+tHUeQltONgCkyCi2AEDHLsJ6iBMlgHL8FeoqokoA2j4CloRMmtwTmj7erHBXPgCWhG6a3JNXKdCiDl1cidVbXZkJoXQRi5t5BrxwoY71FzU8S4JuAIqFkJ2+BFSlEh525b/hr3+k/AklDkNsf6wTT4yv46KIMNpsy+iMdMc47HNWxbsgVcUn7FmLAzzoFAWDsBx+wVP6bUpp5ewI+DOeUx0Wd9D8F70BTGNjkWtqnhmT1JQAHcUgZd8Lo3rQb1LAT8eJVUfgGvHQigGp+V2Z0iAUUl8QH47kAA1XioxIo+bRN8OG8F/oBjwv+Z1nJgX5jpdzQDw0LCjsPmrcW7I/iHScCAEDj03FtD8A0EyuChHgg4KTlJQF3wZ7WELppnBX+dBFSVpJsOBWi1qiRgSwnOgoyD5hmuJdkWCVhTgnTvW3AgYIFrSbZGh0UW/Io5Vp+DQoK7o80pztWMemZbgxeNwCNwDbw1fIfgGZjhU6xPaJgBV8BdsMw5cbZoHsenwYFxkZzl83xTSKTiviCAfCsJLysH3POfC8m8NegyGAGfLP/VmGmfSChgXroR0RSWjEFv2J/nG84cuKFMf4sTCZqXuJd4KaXFVjEG3+tw4eXbNK/YC9oXXs3O8NY8y9
 
9L4BXY5cvLY/Bb2VZ58EOJVcB18DHJq9lRsKr8inyKGVjlmh29mtHs3AHfuhCwy1vXT/Nu2GKQt+UHsGdctyX6eQyNvc+5sfX9Dl7Pe2J/BRgAl2CpwmrsHR0AAAAASUVORK5CYII=);
+}
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/misc/footer.html
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/misc/footer.html 
b/thirdparty/rapidjson-1.1.0/doc/misc/footer.html
new file mode 100644
index 0000000..77f1131
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/misc/footer.html
@@ -0,0 +1,11 @@
+<!-- HTML footer for doxygen 1.8.7-->
+<!-- start footer part -->
+<!--BEGIN GENERATE_TREEVIEW-->
+<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
+  <ul>
+    $navpath
+  </ul>
+</div>
+<!--END GENERATE_TREEVIEW-->
+</body>
+</html>

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/misc/header.html
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/misc/header.html 
b/thirdparty/rapidjson-1.1.0/doc/misc/header.html
new file mode 100644
index 0000000..2dbe721
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/misc/header.html
@@ -0,0 +1,24 @@
+<!-- HTML header for doxygen 1.8.7-->
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+<html xmlns="http://www.w3.org/1999/xhtml";>
+<head>
+<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
+<meta http-equiv="X-UA-Compatible" content="IE=9"/>
+<meta name="generator" content="Doxygen $doxygenversion"/>
+<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END 
PROJECT_NAME-->
+<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
+<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
+<script type="text/javascript" src="$relpath^jquery.js"></script>
+<script type="text/javascript" src="$relpath^dynsections.js"></script>
+$treeview
+$search
+$mathjax
+<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
+$extrastylesheet
+</head>
+<body>
+<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
+<div id="topbanner"><a href="https://github.com/miloyip/rapidjson"; 
title="RapidJSON GitHub"><i class="githublogo"></i></a></div>
+$searchbox
+<!--END TITLEAREA-->
+<!-- end header part -->

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/npm.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/npm.md 
b/thirdparty/rapidjson-1.1.0/doc/npm.md
new file mode 100644
index 0000000..5efa768
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/npm.md
@@ -0,0 +1,31 @@
+## NPM
+
+# package.json {#package}
+
+~~~~~~~~~~js
+{
+  ...
+  "dependencies": {
+    ...
+    "rapidjson": "g...@github.com:miloyip/rapidjson.git"
+  },
+  ...
+  "gypfile": true
+}
+~~~~~~~~~~
+
+# binding.gyp {#binding}
+
+~~~~~~~~~~js
+{
+  ...
+  'targets': [
+    {
+      ...
+      'include_dirs': [
+        '<!(node -e \'require("rapidjson")\')'
+      ]
+    }
+  ]
+}
+~~~~~~~~~~

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/performance.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/performance.md 
b/thirdparty/rapidjson-1.1.0/doc/performance.md
new file mode 100644
index 0000000..988e799
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/performance.md
@@ -0,0 +1,26 @@
+# Performance
+
+There is a [native JSON benchmark collection] [1] which evaluates speed, 
memory usage and code size of various operations among 37 JSON libaries.
+
+[1]: https://github.com/miloyip/nativejson-benchmark
+
+The old performance article for RapidJSON 0.1 is provided 
[here](https://code.google.com/p/rapidjson/wiki/Performance).
+
+Additionally, you may refer to the following third-party benchmarks.
+
+## Third-party benchmarks
+
+* [Basic benchmarks for miscellaneous C++ JSON parsers and 
generators](https://github.com/mloskot/json_benchmark) by Mateusz Loskot (Jun 
2013)
+ * [casablanca](https://casablanca.codeplex.com/)
+ * [json_spirit](https://github.com/cierelabs/json_spirit)
+ * [jsoncpp](http://jsoncpp.sourceforge.net/)
+ * [libjson](http://sourceforge.net/projects/libjson/)
+ * [rapidjson](https://github.com/miloyip/rapidjson/)
+ * [QJsonDocument](http://qt-project.org/doc/qt-5.0/qtcore/qjsondocument.html)
+ 
+* [JSON Parser 
Benchmarking](http://chadaustin.me/2013/01/json-parser-benchmarking/) by Chad 
Austin (Jan 2013)
+ * [sajson](https://github.com/chadaustin/sajson)
+ * [rapidjson](https://github.com/miloyip/rapidjson/)
+ * [vjson](https://code.google.com/p/vjson/)
+ * [YAJL](http://lloyd.github.com/yajl/)
+ * [Jansson](http://www.digip.org/jansson/)

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/performance.zh-cn.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/performance.zh-cn.md 
b/thirdparty/rapidjson-1.1.0/doc/performance.zh-cn.md
new file mode 100644
index 0000000..c20c505
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/performance.zh-cn.md
@@ -0,0 +1,26 @@
+# 性能
+
+有一个 [native JSON benchmark collection][1] 项目，能评估 37 个 JSON 
库在不同操作下的速度、內存用量及代码大小。
+
+[1]: https://github.com/miloyip/nativejson-benchmark
+
+RapidJSON 0.1 版本的性能测试文章位于 
[这里](https://code.google.com/p/rapidjson/wiki/Performance).
+
+此外，你也可以参考以下这些第三方的评测。
+
+## 第三方评测
+
+* [Basic benchmarks for miscellaneous C++ JSON parsers and 
generators](https://github.com/mloskot/json_benchmark) by Mateusz Loskot (Jun 
2013)
+ * [casablanca](https://casablanca.codeplex.com/)
+ * [json_spirit](https://github.com/cierelabs/json_spirit)
+ * [jsoncpp](http://jsoncpp.sourceforge.net/)
+ * [libjson](http://sourceforge.net/projects/libjson/)
+ * [rapidjson](https://github.com/miloyip/rapidjson/)
+ * [QJsonDocument](http://qt-project.org/doc/qt-5.0/qtcore/qjsondocument.html)
+ 
+* [JSON Parser 
Benchmarking](http://chadaustin.me/2013/01/json-parser-benchmarking/) by Chad 
Austin (Jan 2013)
+ * [sajson](https://github.com/chadaustin/sajson)
+ * [rapidjson](https://github.com/miloyip/rapidjson/)
+ * [vjson](https://code.google.com/p/vjson/)
+ * [YAJL](http://lloyd.github.com/yajl/)
+ * [Jansson](http://www.digip.org/jansson/)

http://git-wip-us.apache.org/repos/asf/nifi-minifi-cpp/blob/fd280b5c/thirdparty/rapidjson-1.1.0/doc/pointer.md
----------------------------------------------------------------------
diff --git a/thirdparty/rapidjson-1.1.0/doc/pointer.md 
b/thirdparty/rapidjson-1.1.0/doc/pointer.md
new file mode 100644
index 0000000..b343d78
--- /dev/null
+++ b/thirdparty/rapidjson-1.1.0/doc/pointer.md
@@ -0,0 +1,234 @@
+# Pointer
+
+(This feature was released in v1.1.0)
+
+JSON Pointer is a standardized ([RFC6901]) way to select a value inside a JSON 
Document (DOM). This can be analogous to XPath for XML document. However, JSON 
Pointer is much simpler, and a single JSON Pointer only pointed to a single 
value.
+
+Using RapidJSON's implementation of JSON Pointer can simplify some 
manipulations of the DOM.
+
+[TOC]
+
+# JSON Pointer {#JsonPointer}
+
+A JSON Pointer is a list of zero-to-many tokens, each prefixed by `/`. Each 
token can be a string or a number. For example, given a JSON:
+~~~javascript
+{
+    "foo" : ["bar", "baz"],
+    "pi" : 3.1416
+}
+~~~
+
+The following JSON Pointers resolve this JSON as:
+
+1. `"/foo"` → `[ "bar", "baz" ]`
+2. `"/foo/0"` → `"bar"`
+3. `"/foo/1"` → `"baz"`
+4. `"/pi"` → `3.1416`
+
+Note that, an empty JSON Pointer `""` (zero token) resolves to the whole JSON.
+
+# Basic Usage {#BasicUsage}
+
+The following example code is self-explanatory.
+
+~~~cpp
+#include "rapidjson/pointer.h"
+
+// ...
+Document d;
+
+// Create DOM by Set()
+Pointer("/project").Set(d, "RapidJSON");
+Pointer("/stars").Set(d, 10);
+
+// { "project" : "RapidJSON", "stars" : 10 }
+
+// Access DOM by Get(). It return nullptr if the value does not exist.
+if (Value* stars = Pointer("/stars").Get(d))
+    stars->SetInt(stars->GetInt() + 1);
+
+// { "project" : "RapidJSON", "stars" : 11 }
+
+// Set() and Create() automatically generate parents if not exist.
+Pointer("/a/b/0").Create(d);
+
+// { "project" : "RapidJSON", "stars" : 11, "a" : { "b" : [ null ] } }
+
+// GetWithDefault() returns reference. And it deep clones the default value.
+Value& hello = Pointer("/hello").GetWithDefault(d, "world");
+
+// { "project" : "RapidJSON", "stars" : 11, "a" : { "b" : [ null ] }, "hello" 
: "world" }
+
+// Swap() is similar to Set()
+Value x("C++");
+Pointer("/hello").Swap(d, x);
+
+// { "project" : "RapidJSON", "stars" : 11, "a" : { "b" : [ null ] }, "hello" 
: "C++" }
+// x becomes "world"
+
+// Erase a member or element, return true if the value exists
+bool success = Pointer("/a").Erase(d);
+assert(success);
+
+// { "project" : "RapidJSON", "stars" : 10 }
+~~~
+
+# Helper Functions {#HelperFunctions}
+
+Since object-oriented calling convention may be non-intuitive, RapidJSON also 
provides helper functions, which just wrap the member functions with 
free-functions.
+
+The following example does exactly the same as the above one.
+
+~~~cpp
+Document d;
+
+SetValueByPointer(d, "/project", "RapidJSON");
+SetValueByPointer(d, "/stars", 10);
+
+if (Value* stars = GetValueByPointer(d, "/stars"))
+    stars->SetInt(stars->GetInt() + 1);
+
+CreateValueByPointer(d, "/a/b/0");
+
+Value& hello = GetValueByPointerWithDefault(d, "/hello", "world");
+
+Value x("C++");
+SwapValueByPointer(d, "/hello", x);
+
+bool success = EraseValueByPointer(d, "/a");
+assert(success);
+~~~
+
+The conventions are shown here for comparison:
+
+1. `Pointer(source).<Method>(root, ...)`
+2. `<Method>ValueByPointer(root, Pointer(source), ...)`
+3. `<Method>ValueByPointer(root, source, ...)`
+
+# Resolving Pointer {#ResolvingPointer}
+
+`Pointer::Get()` or `GetValueByPointer()` function does not modify the DOM. If 
the tokens cannot match a value in the DOM, it returns `nullptr`. User can use 
this to check whether a value exists.
+
+Note that, numerical tokens can represent an array index or member name. The 
resolving process will match the values according to the types of value.
+
+~~~javascript
+{
+    "0" : 123,
+    "1" : [456]
+}
+~~~
+
+1. `"/0"` → `123`
+2. `"/1/0"` → `456`
+
+The token `"0"` is treated as member name in the first pointer. It is treated 
as an array index in the second pointer.
+
+The other functions, including `Create()`, `GetWithDefault()`, `Set()` and 
`Swap()`, will change the DOM. These functions will always succeed. They will 
create the parent values if they do not exist. If the parent values do not 
match the tokens, they will also be forced to change their type. Changing the 
type also mean fully removal of that DOM subtree.
+
+Parsing the above JSON into `d`, 
+
+~~~cpp
+SetValueByPointer(d, "1/a", 789); // { "0" : 123, "1" : { "a" : 789 } }
+~~~
+
+## Resolving Minus Sign Token
+
+Besides, [RFC6901] defines a special token `-` (single minus sign), which 
represents the pass-the-end element of an array. `Get()` only treats this token 
as a member name '"-"'. Yet the other functions can resolve this for array, 
equivalent to calling `Value::PushBack()` to the array.
+
+~~~cpp
+Document d;
+d.Parse("{\"foo\":[123]}");
+SetValueByPointer(d, "/foo/-", 456); // { "foo" : [123, 456] }
+SetValueByPointer(d, "/-", 789);    // { "foo" : [123, 456], "-" : 789 }
+~~~
+
+## Resolving Document and Value
+
+When using `p.Get(root)` or `GetValueByPointer(root, p)`, `root` is a (const) 
`Value&`. That means, it can be a subtree of the DOM.
+
+The other functions have two groups of signature. One group uses `Document& 
document` as parameter, another one uses `Value& root`. The first group uses 
`document.GetAllocator()` for creating values. And the second group needs user 
to supply an allocator, like the functions in DOM.
+
+All examples above do not require an allocator parameter, because the first 
parameter is a `Document&`. But if you want to resolve a pointer to a subtree, 
you need to supply the allocator as in the following example:
+
+~~~cpp
+class Person {
+public:
+    Person() {
+        document_ = new Document();
+        // CreateValueByPointer() here no need allocator
+        SetLocation(CreateValueByPointer(*document_, "/residence"), ...);
+        SetLocation(CreateValueByPointer(*document_, "/office"), ...);
+    };
+
+private:
+    void SetLocation(Value& location, const char* country, const char* 
addresses[2]) {
+        Value::Allocator& a = document_->GetAllocator();
+        // SetValueByPointer() here need allocator
+        SetValueByPointer(location, "/country", country, a);
+        SetValueByPointer(location, "/address/0", address[0], a);
+        SetValueByPointer(location, "/address/1", address[1], a);
+    }
+
+    // ...
+
+    Document* document_;
+};
+~~~
+
+`Erase()` or `EraseValueByPointer()` does not need allocator. And they return 
`true` if the value is erased successfully.
+
+# Error Handling {#ErrorHandling}
+
+A `Pointer` parses a source string in its constructor. If there is parsing 
error, `Pointer::IsValid()` returns `false`. And you can use 
`Pointer::GetParseErrorCode()` and `GetParseErrorOffset()` to retrieve the 
error information.
+
+Note that, all resolving functions assumes valid pointer. Resolving with an 
invalid pointer causes assertion failure.
+
+# URI Fragment Representation {#URIFragment}
+
+In addition to the string representation of JSON pointer that we are using 
till now, [RFC6901] also defines the URI fragment representation of JSON 
pointer. URI fragment is specified in [RFC3986] "Uniform Resource Identifier 
(URI): Generic Syntax".
+
+The main differences are that a the URI fragment always has a `#` (pound sign) 
in the beginning, and some characters are encoded by percent-encoding in UTF-8 
sequence. For example, the following table shows different C/C++ string 
literals of different representations.
+
+String Representation | URI Fragment Representation | Pointer Tokens (UTF-8)
+----------------------|-----------------------------|------------------------
+`"/foo/0"`            | `"#/foo/0"`                 | `{"foo", 0}`
+`"/a~1b"`             | `"#/a~1b"`                  | `{"a/b"}`
+`"/m~0n"`             | `"#/m~0n"`                  | `{"m~n"}`
+`"/ "`                | `"#/%20"`                   | `{" "}`
+`"/\0"`               | `"#/%00"`                   | `{"\0"}`
+`"/€"`                | `"#/%E2%82%AC"`             | `{"€"}`
+
+RapidJSON fully support URI fragment representation. It automatically detects 
the pound sign during parsing.
+
+# Stringify
+
+You may also stringify a `Pointer` to a string or other output streams. This 
can be done by:
+
+~~~
+Pointer p(...);
+StringBuffer sb;
+p.Stringify(sb);
+std::cout << sb.GetString() << std::endl;
+~~~
+
+It can also stringify to URI fragment reprsentation by 
`StringifyUriFragment()`.
+
+# User-Supplied Tokens {#UserSuppliedTokens}
+
+If a pointer will be resolved multiple times, it should be constructed once, 
and then apply it to different DOMs or in different times. This reduce time and 
memory allocation for constructing `Pointer` multiple times.
+
+We can go one step further, to completely eliminate the parsing process and 
dynamic memory allocation, we can establish the token array directly:
+
+~~~cpp
+#define NAME(s) { s, sizeof(s) / sizeof(s[0]) - 1, kPointerInvalidIndex }
+#define INDEX(i) { #i, sizeof(#i) - 1, i }
+
+static const Pointer::Token kTokens[] = { NAME("foo"), INDEX(123) };
+static const Pointer p(kTokens, sizeof(kTokens) / sizeof(kTokens[0]));
+// Equivalent to static const Pointer p("/foo/123");
+~~~
+
+This may be useful for memory constrained systems.
+
+[RFC3986]: https://tools.ietf.org/html/rfc3986
+[RFC6901]: https://tools.ietf.org/html/rfc6901

Reply via email to