6.2 CTC Compiler
6.2.1 CTC Compiler Example
In this section, we show an example for the CTC Compiler. The same Notebook schema example used in Section 4.1.4.1 will be used here. For convenience reasons, the Notebook XML Schema is shown again here in Figure 6.6.
Section 6.2. CTC Compiler 103
Figure 6.5: Internal process of the CTC Compiler.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> <xs:element name="notebook">
<xs:complexType>
<xs:sequence maxOccurs="unbounded"> <xs:element name="note"type="Note"/> </xs:sequence>
<xs:attribute ref="date"/> </xs:complexType>
</xs:element>
<xs:complexType name="Note"> <xs:sequence>
<xs:element name="subject" type="xs:string"/> <xs:element name="body" type="xs:string"/> </xs:sequence>
<xs:attribute ref="date" use="required"/> <xs:attribute name="category"type="xs:string"/> </xs:complexType>
<xs:attribute name="date" type="xs:date"/> </xs:schema>
Table 6.1: Schema context Notebook example, after Context Collapsing. The content of the Children row represents the tuple (Template, Type, IsOptional, IsArray, Context). Cn represents the eContext Id and tn the template identifier, x denotes complex, s string, c constant, d date-time, t True and f False.
Attribute Id
C1 (ROOT) C2 (CONTENT) C3 (NOTEBOOK) C4 (NOTE) C5 (NOTE-ATT)
MultipleParents f f f f f
Order fixed choice fixed fixed dynamic
Children (t1,c,t,f,-) (-,x,f,f,C2) (t2,x,t,f,C3) (t3,d,t,f,-) (t3,d,t,f,-) (t4,x,f,t,C4) (-,x,f,f,C5) (-,s,f,f,-) (-,s,f,f,-) (t3,d,f,f,-) (t5,s,t,f,-)
Table 6.2: Notebook XML Schema’s templates, after Context Collapsing. Symbol ’@’ is used to represent the place-holders’ positions
t1 <?xml version="1.0" encoding="UTF-8"?> t2 <notebook @> @ </notebook> t3 date=@ t4 <note category=@ @> <subject>@</subject> <body>@</body> </note> t5 category=@
The schema context and templates produced after parsing, processing and collapsing the schema are shown in Table 6.1 and Table 6.2, also copied from Section 4.1.4.1 for convenience reasons.
The CTC Compiler converts the schema context shown in Table 6.1 to C code and creates the C files “notebook-sc.c” and “notebook-sc.h”. In the same manner, the C code stubs to access the notebook data model schema context is stored in the files “notebook-stub.c” and “notebook-stub.h”.
Once the Notebook schema is processed and all the specific code files are created, the CTC Compiler creates the files for the Context Table component and includes the necessary references to the Notebook schema’s schema context. Finally, the CTC Compiler includes the templates of the Notebook schema into the Template Table and creates the files “template-table.c” and “template-table.h”.
A code fragment of each file is shown in the following figures. Figure 6.7 and Figure 6.8 respectively contain a code snippet of the schema context and Template Table source code files for the Notebook XML Schema example (i.e. “notebook-sc.c” and “template-table.c” files). Two different code fragments of the “notebook-stub.c” are shown in Figure 6.9 and Figure 6.10, one of the C structure bindings and the other of the C function wrappers.
Section 6.2. CTC Compiler 105 #include"notebook−sc.h" #include"template−table.h" constschema_context_s sc_ = { "sc_", // uri 6, // element_number &ec__root // element_contexts };
static constelement_s _children__root[] = {
/∗0∗/ {24, &template_table_notebook[0], NULL}, //_prolog, "<?xml version=\"1.0\" encoding=\"←- UTF−8\"?>"
/∗1∗/ {9, &template_table_notebook[1], &ec__body} //_body, "@"
};
constelement_context_s ec__root = {
content_fixed, 2, _children__root };
static constelement_s _children__body[] = {
/∗0∗/ {89, &template_table_notebook[2], &ec_notebook},//notebook, "<notebook@>@</notebook←- >"
/∗1∗/ {86, &template_table_notebook[3], NULL} //date, " date=\"@\""
};
constelement_context_s ec__body = {
content_choice, 2, _children__body };
Figure 6.7: Code snippet of the “notebook-sc.c” file.
consttemplate_s template_table_notebook[] = {
/∗0∗/ {42,"<?xml version=\"1.0\" encoding=\"UTF−8\"?>"}, /∗1∗/ {23,"<notebook@>@</notebook>"}, /∗2∗/ {11," date=\"@\""}, /∗3∗/ {15," category=\"@\""}, /∗4∗/ {48,"<note@><subject>@</subject><body>@</body></note>"}, };
structNote { char∗subject; char∗body; char∗date; char∗category; }; structnotebook { int__notebook_sequence_size; struct__notebook_sequence {
structNote ∗note;
} ∗__notebook_sequence;
char∗date;
};
Figure 6.9: Code snippet of the C structure binding of the Notebook XML Schema document.
Note∗ Note_create(void);
intNote_destroy(Note∗ Note);
intNote_decode(const char∗in_stream,intis_size, Note∗ Note); intNote_encode(constNote∗ Note,char∗out_stream,intos_size);
Figure 6.10: Code snippet of the basic C function wrappers for the Note structure binding of the Notebook XML Schema document.
Section 6.3. Summary and Conclusions 107
6.3
Summary and Conclusions
In this section, we described the CTC Library and its main components. The CTC Library provides an implementation of the CTC capabilities, including the management of the context table and template table, the execution of the CTC Codification Algorithm and the mechanisms of the CTC Communication Model. The CTC Library is embedded in applications in order to access the CTC capabilities as well as encode and decode data streams.
The CTC Library provides a modular approach that allows to tailor the library capabilities to the needs and resources of the devices. This is specially important for resource-constrained devices in order to reduce the size of the library as much as possible (and make the most of the available memory) while implementing all the required functionalities. As will be shown later in Section 7.1, the CTC Library has a very small memory footprint and provides efficient CTC implementation suitable for the most resource-constrained devices.
The CTC Library is complemented by the CTC Compiler tool, easing and automating the implementation of the context table, template table and data model bindings to native code.
7
|
Evaluation
This chapter contains all the empirical tests performed during the development of the work presented in this document. The purpose of these tests is to evaluate and verify the performed work in terms of compression size, processing time and memory usage, as well as the sustained hypothesis.
Section 7.1 contains the performance evaluation of a prototype implementation of CTC, using XML as the specific data format. This section also includes a comparison of CTC to the leading XML compressor: EXI. Section 7.2 extends the compression efficiency evaluation of CTC for the JSON case. This section also contains a comparison of CTC applied to XML and JSON documents Finally, Section 7.3 shows the CTC evaluation within a typical REST architecture deployment and focused on the impact of CTC on the transmission efficiency and communication load.
7.1
XML Compression Performance Evaluation
In this section, two performance tests are presented in order to compare CTC and EXI imple- mentations. The results are grouped into three sections, each one focused on one performance metric: compression size, processing time and memory usage.
In the first test, a set of XML instances are compressed by using (a) EXIficient [16b], an EXI implementation, and (b) a prototype implementation of the CTC approach. The purpose of this test is to evaluate and compare the compression rate of both implementations.
In the second test, the compressed data streams obtained from the previous test are decom- pressed to analyse the required processing time and memory usage. For the decodification of the EXI streams, another EXI implementation more suited to resource-constrained systems is used, Embeddable EXI Processor (EXIP) [KPED14]. EXIP is considered here because, to the au- thor’s knowledge, it is the best suited to resource-constrained systems. Other implementations targeted at resource-constrained systems, such as WS4D-uEXI [WS4], only implement a subset of the EXI specification and/or are somewhat outdated.
The tests were performed in a CC2650 MCU [CC2] running at 48MHz. The test applications, as well as the code under test, were compiled with the optimizations turned on.
The set of XML documents used in the tests is composed of the XML Schema instances for Network Configuration Protocol (netconf ) [net], Media Types for Sensor Markup Language
(SenML) [JSA+18], Data Types definitions for OPC-UA (OPC-UA Types) [fou] and Zigbee Smart Energy Profile 2.0 (SEP2) [SEP], presented in the EXIP evaluation paper [KPED14]. As in [KPED14], three different documents per XML Schema are considered. Additionally, the notebook XML document used as an example in the EXI Primer web page [PPG14] is also included.