-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathjadn-v1.0-cs01.html
2394 lines (2351 loc) · 245 KB
/
jadn-v1.0-cs01.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
<head>
<meta name="description" content="This specification defines JSON Abstract Data Notation (JADN), an information modeling language.">
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<title>Specification for JSON Abstract Data Notation Version 1.0</title>
<link rel="stylesheet" href="https://docs.oasis-open.org/templates/css/markdown-styles-v1.7.3a.css" />
</head>
<body>
<h2 id="oasis-logo"><img src="http://docs.oasis-open.org/templates/OASISLogo-v3.0.png" alt="OASIS Logo" /></h2>
<hr style="page-break-before: avoid" />
<h1big id="specification-for-json-abstract-data-notation-jadn-version-10">Specification for JSON Abstract Data Notation (JADN) Version 1.0</h1big>
<h2 id="committee-specification-01">Committee Specification 01</h2>
<h2 id="17-august-2021">17 August 2021</h2>
<h4 id="this-stage">This stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.md">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.pdf">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.pdf</a></p>
<h4 id="previous-stage">Previous stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.md">https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.html">https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.pdf">https://docs.oasis-open.org/openc2/jadn/v1.0/csd02/jadn-v1.0-csd02.pdf</a></p>
<h4 id="latest-stage">Latest stage:</h4>
<p><a href="https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.md">https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.md</a> (Authoritative) <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html">https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html</a> <br />
<a href="https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.pdf">https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.pdf</a></p>
<h4 id="technical-committee">Technical Committee:</h4>
<p><a href="https://www.oasis-open.org/committees/openc2/">OASIS Open Command and Control (OpenC2) TC</a></p>
<h4 id="chair">Chair:</h4>
<p>Duncan Sparrell (<a href="mailto:duncan@sfractal.com">duncan@sfractal.com</a>), <a href="http://www.sfractal.com/">sFractal Consulting LLC</a></p>
<h4 id="editor">Editor:</h4>
<p>David Kemp (<a href="mailto:d.kemp@cyber.nsa.gov">d.kemp@cyber.nsa.gov</a>), <a href="https://www.nsa.gov/">National Security Agency</a></p>
<h4 id="additional-artifacts">Additional artifacts:</h4>
<p>This prose specification is one component of a Work Product that also includes:</p>
<ul>
<li>JSON schema for JADN documents: <a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.json">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.json</a></li>
<li>JADN schema for JADN documents: <a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.jadn">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/schemas/jadn-v1.0.jadn</a></li>
</ul>
<h4 id="abstract">Abstract:</h4>
<p>JSON Abstract Data Notation (JADN) is a UML-based information modeling language that defines data structure independently of data format. Information models are used to define and generate physical data models, validate information instances, and enable lossless translation across data formats. A JADN specification consists of two parts: type definitions that comprise the information model, and serialization rules that define how information instances are represented as data. The information model is itself an information instance that can be serialized and transferred between applications. The model is documented using a compact and expressive interface definition language, property tables, or entity relationship diagrams, easing integration with existing design processes and architecture tools.</p>
<h4 id="status">Status:</h4>
<p>This document was last revised or approved by the OASIS Open Command and Control (OpenC2) TC on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical">https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#technical</a>.</p>
<p>TC members should send comments on this specification to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at <a href="https://www.oasis-open.org/committees/openc2/">https://www.oasis-open.org/committees/openc2/</a>.</p>
<p>This specification is provided under the <a href="https://www.oasis-open.org/policies-guidelines/ipr#Non-Assertion-Mode">Non-Assertion</a> Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (<a href="https://www.oasis-open.org/committees/openc2/ipr.php">https://www.oasis-open.org/committees/openc2/ipr.php</a>).</p>
<p>Note that any machine-readable content (<a href="https://www.oasis-open.org/policies-guidelines/tc-process#wpComponentsCompLang">Computer Language Definitions</a>) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.</p>
<h4 id="key-words">Key words:</h4>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [<a href="#rfc2119">RFC2119</a>] and [<a href="#rfc8174">RFC8174</a>] when, and only when, they appear in all capitals, as shown here.</p>
<h4 id="citation-format">Citation format:</h4>
<p>When referencing this specification the following citation format should be used:</p>
<p><strong>[JADN-v1.0]</strong><br />
<em>JSON Abstract Data Notation Version 1.0</em>. Edited by David Kemp. 17 August 2021. OASIS Committee Specification 01. <a href="https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html">https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html</a>. Latest stage: <a href="https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html">https://docs.oasis-open.org/openc2/jadn/v1.0/jadn-v1.0.html</a>.</p>
<hr />
<h2 id="notices">Notices</h2>
<p>Copyright © OASIS Open 2021. All Rights Reserved.</p>
<p>Distributed under the terms of the OASIS <a href="https://www.oasis-open.org/policies-guidelines/ipr">IPR Policy</a>.</p>
<p>The name "OASIS" is a trademark of <a href="https://www.oasis-open.org/">OASIS</a>, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs.</p>
<p>For complete copyright information please see the Notices section in the Appendix.</p>
<hr />
<h1 id="table-of-contents">Table of Contents</h1>
<ul type="none">
<li><a href="#1-introduction">1 Introduction</a>
<ul type="none">
<li><a href="#11-changes-from-earlier-versions">1.1 Changes from earlier versions</a></li>
<li><a href="#12-glossary">1.2 Glossary</a>
<ul type="none">
<li><a href="#121-definitions-of-terms">1.2.1 Definitions of terms</a></li>
<li><a href="#122-acronyms-and-abbreviations">1.2.2 Acronyms and abbreviations</a></li>
</ul></li>
</ul></li>
<li><a href="#2-information-vs-data">2 Information vs. Data</a>
<ul type="none">
<li><a href="#21-graph-modeling">2.1 Graph Modeling</a></li>
<li><a href="#22-information-modeling">2.2 Information Modeling</a></li>
<li><a href="#23-information-definition-formats">2.3 Information Definition Formats</a></li>
<li><a href="#24-implementation">2.4 Implementation</a></li>
</ul></li>
<li><a href="#3-jadn-types">3 JADN Types</a>
<ul type="none">
<li><a href="#31-type-definitions">3.1 Type Definitions</a>
<ul type="none">
<li><a href="#311-requirements">3.1.1 Requirements</a></li>
<li><a href="#312-name-formats">3.1.2 Name Formats</a></li>
<li><a href="#313-upper-bounds">3.1.3 Upper Bounds</a></li>
<li><a href="#314-descriptions">3.1.4 Descriptions</a></li>
</ul></li>
<li><a href="#32-options">3.2 Options</a>
<ul type="none">
<li><a href="#321-type-options">3.2.1 Type Options</a></li>
<li><a href="#322-field-options">3.2.2 Field Options</a></li>
</ul></li>
<li><a href="#33-jadn-extensions">3.3 JADN Extensions</a>
<ul type="none">
<li><a href="#331-type-definition-within-fields">3.3.1 Type Definition Within Fields</a></li>
<li><a href="#332-field-multiplicity">3.3.2 Field Multiplicity</a></li>
<li><a href="#333-derived-enumerations">3.3.3 Derived Enumerations</a></li>
<li><a href="#334-mapof-with-enumerated-key">3.3.4 MapOf With Enumerated Key</a></li>
<li><a href="#335-pointers">3.3.5 Pointers</a></li>
<li><a href="#336-links">3.3.6 Links</a></li>
</ul></li>
</ul></li>
<li><a href="#4-serialization">4 Serialization</a>
<ul type="none">
<li><a href="#41-verbose-json-serialization">4.1 Verbose JSON Serialization</a></li>
<li><a href="#42-compact-json-serialization">4.2 Compact JSON Serialization:</a></li>
<li><a href="#43-concise-json-serialization">4.3 Concise JSON Serialization:</a></li>
<li><a href="#44-cbor-serialization">4.4 CBOR Serialization</a></li>
</ul></li>
<li><a href="#5-definition-formats">5 Definition Formats</a>
<ul type="none">
<li><a href="#51-jadn-idl-format">5.1 JADN-IDL Format</a></li>
<li><a href="#52-table-style">5.2 Table Style</a></li>
<li><a href="#53-entity-relationship-diagrams">5.3 Entity Relationship Diagrams</a></li>
</ul></li>
<li><a href="#6-schema-packages">6 Schema Packages</a></li>
<li><a href="#7-conformance">7 Conformance</a></li>
<li><a href="#appendix-a-references">Appendix A. References</a>
<ul type="none">
<li><a href="#a1-normative-references">A.1 Normative References</a></li>
<li><a href="#a2-informative-references">A.2 Informative References</a></li>
</ul></li>
<li><a href="#appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</a></li>
<li><a href="#appendix-c-acknowledgments">Appendix C. Acknowledgments</a>
<ul type="none">
<li><a href="#c1-special-thanks">C.1 Special Thanks</a></li>
<li><a href="#c2-participants">C.2 Participants</a></li>
</ul></li>
<li><a href="#appendix-d-revision-history">Appendix D. Revision History</a></li>
<li><a href="#appendix-e-json-schema-for-jadn-documents">Appendix E. JSON Schema for JADN Documents</a></li>
<li><a href="#appendix-f-jadn-meta-schema-for-jadn-documents">Appendix F. JADN Meta-schema for JADN Documents</a>
<ul type="none">
<li><a href="#f1-package">F.1 Package</a></li>
<li><a href="#f2-type-definitions">F.2 Type Definitions</a></li>
</ul></li>
<li><a href="#appendix-g-jadn-type-definitions-from-this-document">Appendix G. JADN Type Definitions From This Document</a></li>
<li><a href="#appendix-h-notices">Appendix H. Notices</a></li>
</ul>
<hr />
<h1 id="1-introduction">1 Introduction</h1>
<p><a href="#rfc3444">RFC 3444</a>, "Information Models and Data Models", notes that the main purpose of an information model is to model objects at a conceptual level, independent of specific implementations or protocols used to transport the data. <a href="#rfc8477">RFC 8477</a>, "IoT Semantic Interoperability Workshop 2016", describes a lack of consistency across Standards Developing Organizations in defining application layer data, attributing it to the lack of an encoding-independent standardization of the information represented by that data. This document defines an information modeling language intended to address that gap. JADN is a <a href="#fdt">formal description technique</a> that combines type constraints from the Unified Modeling Language <a href="#uml">UML</a> with data abstraction based on information theory and structural organization using results from graph theory.</p>
<p>As shown in Figure 1, industry has multiple, often conflicting definitions of data modeling terms, including the term "<a href="#ie">Information Engineering</a>", which at one time referred to <a href="#datamod">data modeling</a> but is now more closely aligned with information theory and machine learning.</p>
<ul>
<li>Ackoff's <a href="#diek">Knowlege Hierarchy</a> defines data as "symbols that are properties of observables" and informally calls information "descriptions inferred from data".</li>
<li>UML defines DataTypes (simple classifiers where instances are distinguished only by value) and Classes (structured classifiers where instances have behavior, inheritance, roles, and other complex characteristics).</li>
<li>Traditional data modeling defines conceptual, logical and physical data models without considering information at all.</li>
<li>Information modeling formalizes the relationship between information and data, defining a technology-agnostic information layer that lies between the logical data model and multiple technology-specific physical data models.</li>
</ul>
<p><img src="images/info-engineering.jpg" alt="Information Engineering" /></p>
<h6 id="figure-1-information-engineering-terminology">Figure 1: Information Engineering Terminology</h6>
<p>UML class models and diagrams are commonly referred to as "Data Models", but they model knowledge of real-world entities using classes. In contrast, information models model data itself using datatypes. A practical distinction is that class models are undirected graphs with an unlimited variety of classes and semantic relationships, while information models are directed graphs with a small predefined set of base datatypes and only two kinds of relationship: "contain" and "reference". Designing an information model from a class/logical model is largely a matter of assigning the kind and direction of each relationship, establishing identifiers for all referenceable datatypes, and selecting the kind of each datatype from among the base types defined by an information modeling language. Converting an information model to a data model means applying serialization rules for each base type that produce physical data in the desired format.</p>
<h2 id="11-changes-from-csd-01">1.1 Changes from CSD 01</h2>
<ul>
<li>Added serialization style description to <a href="#22-information-modeling">Section 2.2</a>.</li>
<li>Removed the Null base type from <a href="#table-3-1-jadn-base-types">Table 3.1</a>.</li>
<li>Added default values for type definition elements to <a href="#311-requirements">Section 3.1.1</a></li>
<li>Raised the default maximum length for type and field names from 32 to 64 characters (<a href="#312-name-formats">Section 3.1.2</a>).</li>
</ul>
<h2 id="12-glossary">1.2 Glossary</h2>
<h3 id="121-definitions-of-terms">1.2.1 Definitions of terms</h3>
<ul>
<li><p><strong>Information</strong>: A measure of the entropy (novelty, or "news value") of a message. Information is the minimum data needed to represent the essential meaning of a message, excluding data that is known <em>a priori</em> and data that does not affect meaning.</p></li>
<li><p><strong>Information Model</strong>: An abstract schema that defines the structure and value constraints of information used within and across applications, irrespective of data format.</p></li>
<li><p><strong>Data Model</strong>: A concrete schema that defines the structure and value constraints of serialized data. A single information model corresponds to multiple equivalent data models; two data models are equivalent if they represent the same information.</p></li>
<li><p><strong>Graph</strong>: A mathematical structure used to model pairwise relationships between objects. An information model is a graph where nodes are information type definitions and edges are relationships between types.</p></li>
<li><p><strong>Package</strong>: A container that defines a namespace for the set of types it contains. A type can reference types from another package using the referenced namespace.</p></li>
<li><p><strong>Document</strong>: A series of octets described by a data format applied to an information model, or equivalently, by a data model.</p></li>
<li><p><strong>Well-formed</strong>: A well-formed document follows the syntactic structure of the document's media type.</p></li>
<li><p><strong>Valid</strong>: An instance is valid if it satisfies the constraints defined in an information model. A document is valid if it is well-formed and also corresponds to a valid instance.</p></li>
<li><p><strong>Data Format</strong>: A data format, defined by serialization rules, specifies the media type (XML, JSON, Protobuf, ...), design goals (human readability, efficiency), and style preferences for documents in that format.</p></li>
<li><p><strong>Instance</strong>: An instance, or API value, is an item of information that satisfies the structure and value constraints defined by a type. Types are defined by an information modeling language; JADN built-in types are:</p>
<ul>
<li><strong>Primitive:</strong> Boolean, Binary, Integer, Number, String</li>
<li><strong>Enumeration:</strong> Enumerated</li>
<li><strong>Specialization:</strong> Choice</li>
<li><strong>Structured:</strong> Array, ArrayOf, Map, MapOf, Record</li>
</ul></li>
<li><p><strong>Instance Equality</strong>: Two instances are equal if and only if they are of the same type and have the same information value. Formatting differences, including a document's data format, are insignificant. An IPv4 address serialized as a JSON dotted-quad is equal to an IPv4 address serialized as a CBOR byte string if and only if they have the same 32 bit value. A Record instance serialized as an array is equal to a Record instance serialized as a map if and only if they have the same keys and the same value for each key.</p></li>
<li><p><strong>Serialization</strong>: Serialization, or encoding, converts application information into a document. De-serialization, or decoding, converts a document into information instances usable by applications.</p></li>
<li><p><strong>Description</strong>: Description elements are reserved for comments from schema authors to readers or maintainers of the schema, and are ignored by applications using the schema.</p></li>
</ul>
<h3 id="122-acronyms-and-abbreviations">1.2.2 Acronyms and abbreviations</h3>
<ul>
<li><strong>DAG</strong>: Directed Acyclic Graph</li>
<li><strong>DM</strong>: Data Model</li>
<li><strong>IM</strong>: Information Model</li>
<li><strong>UML</strong>: Unified Modeling Language</li>
</ul>
<!--
### 1.2.3 Document conventions
- Naming conventions
- Font colors and styles
- Typographic conventions
-->
<hr />
<h1 id="2-information-vs-data">2 Information vs. Data</h1>
<p>Information is <em>what</em> needs to be communicated between applications, and data is <em>how</em> that information is represented when communicating. More formally, information is the unexpected data, or entropy, contained in a document. When information is serialized for transmission in a canonical format, the additional data used for purposes such as text conversion, delimiting, and framing contains no information because it is known <em>a priori</em>. If the serialization is non-canonical, any additional entropy introduced during serialization (e.g., whitespace, leading zeroes, field reordering, case-insensitive capitalization) is discarded on deserialization.</p>
<p>A variable that can take on 2^N different values conveys at most N bits of information. For example, an IPv4 address that can specify 2^32 different addresses is, by definition, a 32 bit value*. But different data may be used to represent that information:</p>
<ul>
<li>IPv4 dotted-quad contained in a JSON string: "192.168.141.240" (17 bytes / 136 bits).</li>
<li>IPv4 dotted-quad contained in a CBOR string: 0x6F3139322E3136382E3134312E323430 (16 bytes / 128 bits)</li>
<li>Hex value contained in a JSON string: "C0A88DF0" (10 bytes / 80 bits)</li>
<li>CBOR byte string: 0x44c0a88df0 (5 bytes / 40 bits).</li>
<li>IPv4 packet (unadorned RFC791-style serialization): 0xc0a88df0 (4 bytes / 32 bits).</li>
</ul>
<p>The 13 extra bytes used to format a 4 byte IP address as a dotted quad are useful for display purposes, but provide no information to the receiving application. Field names and enumerated strings selected from a dozen possibliities convey less than four <em>bits</em> of information, while the strings themselves may be half a dozen to hundreds of <em>bytes</em> of data. By distinguishing information from data, information modeling is key to effectively using both binary data formats such as Protobuf and CBOR and text formats such as XML and JSON.</p>
<p>* <em>Note: all references to information assume independent uniformly-distributed values. Non-uniform or correlated data contains less than one byte of information per data byte, but source coding is beyond the scope of this specification.</em></p>
<h2 id="21-graph-modeling">2.1 Graph Modeling</h2>
<p>A JADN information model is a set of type definitions (<a href="#31-type-definitions">Section 3.1</a>). Each field in a structured type may be associated with another model-defined type, and the set of associations between types forms a directed graph. Each association is either a container or a reference, and the direction of each edge is toward the contained or referenced type.</p>
<p>The container edges of an information model must be acyclic in order to ensure that:</p>
<ol>
<li>every model has one or more roots,</li>
<li>every path from a root to any leaf has finite length, and equivalently</li>
<li>every instance has finite nesting depth.</li>
</ol>
<p>There is no restriction on reference edges, so any container cycles in a model can be broken by converting one or more containers to references.</p>
<p>Logical models are undirected graphs, and a few results from graph theory are useful when constructing information models from logical models:</p>
<ul>
<li>A tree is a connected acyclic undirected graph, where any pair of nodes is connected by exactly one path.</li>
<li>A directed (or rooted) tree is a hierarchy. A directed tree is constructed from an (undirected) tree by selecting one node as root and assigning all edge directions either toward or away from the root.</li>
<li>A directed acyclic graph (DAG) is a directed graph with no directed cycles, or equivalently a directed graph with a topological ordering, a sequence of nodes such that every edge is directed from earlier to later in the sequence.</li>
<li>A DAG differs from a directed tree in that nodes may have more than one parent.</li>
</ul>
<p>A DAG can be refactored into another DAG having the same underlying undirected graph, and two information models with the same underlying graph correspond to the same logical model.</p>
<p>A DAG can be converted to a directed tree by denormalizing (copying subtrees below multi-parent nodes), and a directed tree can be converted to a DAG by normalizing (combining identical subtrees). Reuse of common types is an important goal in both design of information models and analysis of data. However, it is sometimes useful to have a <a href="#graph">tree-structured representation</a> of a document's structure. Converting a DAG into a directed tree supports applications such as model queries that are otherwise difficult to implement, tree-structured content statistics, content transformations, and documentation.</p>
<h2 id="22-information-modeling">2.2 Information Modeling</h2>
<p>Data modeling in the conceptual/logical/physical sense is a top-down process starting with goals and ending with a physical data model. But in practice "data modeling" is often a bottom-up exercise that begins with a collection of desired data instances and ends with a concrete schema. That process could be called data-centric design, in contrast with information-centric design which begins with a set of types that reflect purpose rather than syntax. Because an information model is a graph, information-centric design integrates easily with conceptual and logical models, allowing bottom-up and top-down approaches to meet in the middle.</p>
<table>
<thead>
<tr class="header">
<th>Data-centric</th>
<th>Information-centric</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>A data definition language defines a specific data storage and exchange format.</td>
<td>An information modeling language expresses application needs in terms of desired effects.</td>
</tr>
<tr class="even">
<td>Serialization-specific details are built into applications.</td>
<td>Serialization is a communication function like compression and encryption, provided to applications.</td>
</tr>
<tr class="odd">
<td>JSON Schema defines integer as a value constraint on the JSON number type.</td>
<td>Distinct Integer and Number types reflect mathematical properties regardless of data representation.</td>
</tr>
<tr class="even">
<td>CDDL types: "While arrays and maps are only two representation formats, they are used to specify four loosely-distinguishable styles of composition".</td>
<td>The five structured types are defined unambiguously in terms of composition characteristics. Each type can be represented in multiple data formats.</td>
</tr>
<tr class="odd">
<td>No table composition style exists.</td>
<td>Tables are a fundamental way of organizing information. The Record type holds tabular information that can be represented as either arrays or maps in multiple data formats.</td>
</tr>
<tr class="even">
<td>Instance equality is defined at the data level.</td>
<td>Instance equality is defined in ways meaningful to applications. For example "Optional" and "Nullable" are different at the data level but applications make no logical distinction between "not present" and "present with null value". Record data values in array and map formats are different at the data level but their information instances can be compared for equality.</td>
</tr>
<tr class="odd">
<td>Data-centric design is often Anglocentric, embedding English-language identifiers in protocol data.</td>
<td>Information-centric design encourages definition of natural-language-agnostic protocols while supporting localized text identifiers within applications.</td>
</tr>
</tbody>
</table>
<p>Information-centric design promotes consensus when faced with conflicting developer preferences. Because information is the "substance" of a message, separating substance (information) from style (data format) may make it easier to agree on an information model first, deferring debate on data formats. JADN defines three kinds of information that have alternate representations:</p>
<ol>
<li>Primitive types such as dates and IP addresses: text representation or numeric value (formats)</li>
<li>Enumerations: string value or numeric id (Enumerated vocabularies and field identifiers)</li>
<li>Table rows: column name or position (Records)</li>
</ol>
<p>These alternatives can be grouped into distinct serialization styles:</p>
<table>
<thead>
<tr class="header">
<th>Style:</th>
<th>Verbose<br>repeated name-value pairs</th>
<th>Compact<br>element / property names-values</th>
<th>Concise<br>machine-to-machine optimized</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>Primitives</td>
<td>Text Representation</td>
<td>Text Representation</td>
<td>Integer / Binary / Base64</td>
</tr>
<tr class="even">
<td>Enumerations</td>
<td>String</td>
<td>String</td>
<td>Integer</td>
</tr>
<tr class="odd">
<td>Table Rows</td>
<td>Column Name</td>
<td>Column Position</td>
<td>Column Position</td>
</tr>
</tbody>
</table>
<p>A data format is a serialization style applied to a data language: "Compact JSON", "Concise JSON", "Compact XML", "Verbose CBOR", etc. <a href="#transform">JSON and XML Transformations</a> uses the terms "Friendly" for XML and JSON encodings that associate data types directly with variables and "Unfriendly" for encodings that use repeated variable names in name-value pairs. JADN uses Compact and Verbose respectively to refer to those styles. The name "Verbose" is intended to be descriptive rather than pejorative, as opposed to "Unfriendly". An information model allows designers to compare Verbose and Compact styles for usability, and allows data to be validated and successfully round tripped between a readable JSON style and an actually concise CBOR style.</p>
<p>Reverse-engineering an information model from existing data models allows commonalities and incompatibilities to be identified, facilitating convergence across multiple specifications with similar goals.</p>
<h2 id="23-information-definition-formats">2.3 Information Definition Formats</h2>
<p>Google Protocol Buffers (<a href="#proto">Protobuf</a>) is a typical data definition language. A Protobuf definition looks like:</p>
<pre><code>message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
}
</code></pre>
<p>The corresponding JADN definiton in IDL format (<a href="#5-definition-formats">Section 5</a>) is structurally similar:</p>
<pre><code>Person = Record
1 name String
2 id Integer
3 email String optional
</code></pre>
<p>Property tables (also <a href="#5-definition-formats">Section 5</a>) include the same content:</p>
<p><strong><em>Type: Person (Record)</em></strong></p>
<table>
<thead>
<tr class="header">
<th style="text-align: right;">ID</th>
<th style="text-align: left;">Name</th>
<th style="text-align: left;">Type</th>
<th style="text-align: right;">#</th>
<th style="text-align: left;">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: right;">1</td>
<td style="text-align: left;"><strong>name</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: right;">1</td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: right;">2</td>
<td style="text-align: left;"><strong>id</strong></td>
<td style="text-align: left;">Integer</td>
<td style="text-align: right;">1</td>
<td style="text-align: left;"></td>
</tr>
<tr class="odd">
<td style="text-align: right;">3</td>
<td style="text-align: left;"><strong>email</strong></td>
<td style="text-align: left;">String</td>
<td style="text-align: right;">0..1</td>
<td style="text-align: left;"></td>
</tr>
</tbody>
</table>
<p>The normative form of a JADN type definition (<a href="#3-jadn-types">Section 3</a>) is JSON data:</p>
<pre><code>["Person", "Record", [], "", [
[1, "name", "String", [], ""],
[2, "id", "Integer", [], ""],
[3, "email", "String", ["[0"], ""]
]]
</code></pre>
<p>IDL or property tables are preferred for use in documentation, but conformance is based on normative JSON data.</p>
<h2 id="24-implementation">2.4 Implementation</h2>
<p>Two general approaches can be used to implement IM-based protocol specifications:</p>
<ol>
<li>Translate the IM to a data-format-specific schema language such <a href="#relaxng">Relax-NG</a>, <a href="#jsonschema">JSON Schema</a>, <a href="#proto">Protobuf</a>, or <a href="#rfc8610">CDDL</a>, then use format-specific serialization and validation libraries to process data in the selected format. Applications use data objects specific to each serialization format.</li>
<li>Use the IM directly as a format-independent schema language, using IM serialization and validation libraries to process data without a separate schema generation step. Applications use the same IM instances regardless of serialization format, making it easy to bridge from one format to another.</li>
</ol>
<p>Implementations based on serialization-specific code interoperate with those using an IM serialization library, allowing developers to use either approach.</p>
<hr />
<h1 id="3-jadn-types">3 JADN Types</h1>
<p>An information modeling language's types are defined in terms of the characteristics they provide to applications. JADN's base types are:</p>
<h6 id="table-3-1-jadn-base-types">Table 3-1. JADN Base Types</h6>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">Type</th>
<th style="text-align: left;">Definition</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;"><strong>Primitive</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">A sequence of octets. Length is the number of octets.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Boolean</td>
<td style="text-align: left;">An element with one of two values: true or false.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">A positive or negative whole number.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Number</td>
<td style="text-align: left;">A real number.</td>
</tr>
<tr class="even">
<td style="text-align: left;">String</td>
<td style="text-align: left;">A sequence of characters, each of which has a Unicode codepoint. Length is the number of characters.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Enumeration</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: left;">Enumerated</td>
<td style="text-align: left;">A vocabulary of items where each item has an id and a string value</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Specialization</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: left;">Choice</td>
<td style="text-align: left;">A <a href="#union">discriminated union</a>: one type selected from a set of named or labeled types.</td>
</tr>
<tr class="odd">
<td style="text-align: left;"><strong>Structured</strong></td>
<td style="text-align: left;"></td>
</tr>
<tr class="even">
<td style="text-align: left;">Array</td>
<td style="text-align: left;">An ordered list of labeled fields with positionally-defined semantics. Each field has a position, label, and type.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">ArrayOf(<em>vtype</em>)</td>
<td style="text-align: left;">A collection of fields with the same semantics. Each field has type <em>vtype</em>. Ordering and uniqueness are specified by a collection option.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Map</td>
<td style="text-align: left;">An unordered map from a set of specified keys to values with semantics bound to each key. Each key has an id and name or label, and is mapped to a value type.</td>
</tr>
<tr class="odd">
<td style="text-align: left;">MapOf(<em>ktype</em>, <em>vtype</em>)</td>
<td style="text-align: left;">An unordered map from a set of keys of the same type to values with the same semantics. Each key has key type <em>ktype</em>, and is mapped to value type <em>vtype</em>.</td>
</tr>
<tr class="even">
<td style="text-align: left;">Record</td>
<td style="text-align: left;">An ordered map from a list of keys with positions to values with positionally-defined semantics. Each key has a position and name, and is mapped to a value type. Represents a row in a spreadsheet or database table.</td>
</tr>
</tbody>
</table>
<ul>
<li>An application that uses JADN types MUST exhibit the behavior specified in Table 3-1. Applications MAY use any programming language data types or mechanisms that exhibit the required behavior.</li>
<li>An instance of a Map, MapOf, or Record type MUST NOT have more than one occurrence of each key.</li>
<li>An instance of a Map, MapOf, or Record type MUST NOT have a key of the null type.</li>
<li>An instance of a Map, MapOf, or Record type with a key mapped to a null value MUST compare as equal to an otherwise identical instance without that key.</li>
<li>The length of an Array, ArrayOf or Record instance MUST not include null values after the last non-null value.</li>
<li>Two Array, ArrayOf or Record instances that differ only in the number of trailing nulls MUST compare as equal.</li>
</ul>
<p>As described in Table 3-1, JADN structured types define if their members are <em>Ordered</em> and/or <em>Unique</em>. They also distinguish between homogeneous collections where all members have the same type and heterogeneous collections where each member has a specified type. For homogeneous collections JADN uses the single "ArrayOf" type with a <em>set</em>, <em>unique</em> or <em>unordered</em> option (<a href="#321-type-options">Section 3.2.1</a>) rather than defining separate names for each collection type.</p>
<table>
<thead>
<tr class="header">
<th>Ordered</th>
<th>Unique</th>
<th>Traditional<br>Name</th>
<th>JADN<br>Same Type</th>
<th>JADN<br>Specified Type</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>false</td>
<td>true</td>
<td>Set</td>
<td>ArrayOf+set, MapOf</td>
<td>Map</td>
</tr>
<tr class="even">
<td>true</td>
<td>false</td>
<td>Sequence</td>
<td>ArrayOf</td>
<td>Array</td>
</tr>
<tr class="odd">
<td>true</td>
<td>true</td>
<td>OrderedSet</td>
<td>ArrayOf+unique</td>
<td>Record</td>
</tr>
<tr class="even">
<td>false</td>
<td>false</td>
<td>Bag</td>
<td>ArrayOf+unordered</td>
<td>none</td>
</tr>
</tbody>
</table>
<p>Accessing an element of a collection whose values are neither ordered nor unique returns an arbitrarily-chosen element. Elements of other collections are deterministically accessed by position, value, or for the Record type either position or value.</p>
<h2 id="31-type-definitions">3.1 Type Definitions</h2>
<p>JADN type definitions have a fixed structure designed to be easily describable, easily processed, stable, and extensible.</p>
<ul>
<li><p>Every definition has five elements:</p>
<ol>
<li><strong>TypeName:</strong> the name of the type being defined</li>
<li><strong>BaseType:</strong> the JADN predefined type (<a href="#table-3-1-jadn-base-types">Table 3-1</a>) of the type being defined</li>
<li><strong>TypeOptions:</strong> an array of zero or more <strong>TypeOption</strong> (<a href="#321-type-options">Section 3.2.1</a>) applicable to <strong>BaseType</strong></li>
<li><strong>TypeDescription:</strong> a non-normative comment</li>
<li><strong>Fields:</strong> an array of <strong>Item</strong> or <strong>Field</strong> definitions</li>
</ol></li>
<li><p>If BaseType is a Primitive type, ArrayOf, or MapOf, the <strong>Fields</strong> array MUST be empty:</p></li>
<li><p>If BaseType is Enumerated, each item definition in the <strong>Fields</strong> array MUST have three elements:</p>
<ol>
<li><strong>ItemID:</strong> the integer identifier of the item</li>
<li><strong>ItemValue:</strong> the string value of the item</li>
<li><strong>ItemDescription:</strong> a non-normative comment</li>
</ol></li>
<li><p>If BaseType is Array, Choice, Map, or Record, each field definition in the <strong>Fields</strong> array MUST have five elements:</p>
<ol>
<li><strong>FieldID:</strong> the integer identifier of the field</li>
<li><strong>FieldName:</strong> the name or label of the field</li>
<li><strong>FieldType:</strong> the type of the field, a predefined type or a TypeName with optional Namespace ID prefix <strong>NSID:TypeName</strong></li>
<li><strong>FieldOptions:</strong> an array of zero or more <strong>FieldOption</strong> (<a href="#322-field-options">Section 3.2.2</a>) or <strong>TypeOption</strong> (<a href="#321-type-options">Section 3.2.1</a>) applicable to the field</li>
<li><strong>FieldDescription:</strong> a non-normative comment</li>
</ol></li>
</ul>
<p>The elements are serialized in JSON format as:</p>
<pre><code>[TypeName, BaseType, [TypeOption, ...], TypeDescription, []] (primitive)
[TypeName, BaseType, [TypeOption, ...], TypeDescription, [ (enumerated)
[ItemId, ItemValue, ItemDescription],
...
]]
[TypeName, BaseType, [TypeOption, ...], TypeDescription, [ (structured)
[FieldID, FieldName, FieldType, [FieldOption, TypeOption, ...], FieldDescription],
...
]]
</code></pre>
<p>The same type definition structure can be populated with various levels of detail. At the conceptual level, only TypeName is present, along with FieldType for attributes that reference other model-defined types. At the logical level FieldName is populated for both base and reference attribute types. In a full information model, all Type and Options elements are defined:</p>
<p><img src="images/jadn-defs.jpg" alt="JADN Type Definitions" /></p>
<h3 id="311-requirements">3.1.1 Requirements</h3>
<ul>
<li>TypeName MUST NOT be a JADN predefined type</li>
<li>BaseType MUST be a JADN predefined type</li>
<li>FieldID and FieldName values MUST be unique within a type definition.</li>
<li>If BaseType is Array or Record, FieldID MUST be the ordinal position of the field within the type, numbered consecutively starting at 1.</li>
<li>If BaseType is Enumerated, Choice, or Map, FieldID MAY be any nonconflicting integer tag.</li>
<li>FieldType MUST be a Primitive type, ArrayOf, MapOf, or a model-defined type.</li>
<li>If FieldType is a model-defined type, FieldOptions MUST NOT contain any TypeOption.</li>
<li>ItemValue MAY be any string or MAY be constrained to hold a valid FieldName.</li>
<li>If the <a href="#333-derived-enumerations">Derived Enumerations</a> or <a href="#335-pointers">Pointers</a> extensions are present in type options, the Fields array MUST be empty.</li>
<li>The default value of TypeOptions, Fields, and FieldOptions is the empty Array. The default value of TypeDescription and FieldDescription is the empty String. When serializing, default values MAY be included or omitted in the serialized document. When deserializing, default values MUST be available from the API instance if not present in the document.</li>
</ul>
<p>Including TypeOption values within FieldOptions is an extension (<a href="#331-type-definition-within-fields">Section 3.3.1</a>).</p>
<h3 id="312-name-formats">3.1.2 Name Formats</h3>
<p>JADN does not restrict the syntax of TypeName and FieldName, but naming conventions can aid readability of specifications.</p>
<ul>
<li>JADN specifications MAY override the default name formats by defining one or more of:
<ul>
<li>The permitted format for TypeName</li>
<li>The permitted format for FieldName</li>
<li>The permitted format for the Namespace Identifier (NSID) used in type references</li>
<li>A "System" character used in tool-generated or specially-processed type names</li>
</ul></li>
<li>Schema authors MUST NOT create FieldNames containing the <a href="#rfc6901">JSON Pointer</a> field separator "/", which is reserved for use in the <a href="#335-pointers">Pointers</a> extension</li>
<li>Schema authors SHOULD NOT create TypeNames containing the System character, but schema processing tools MAY do so</li>
<li>Specifications that do not define alternate name formats MUST use the definitions in Figure 3-1 expressed as <a href="#rfc5234">ABNF</a> and <a href="#es9">Regular Expression</a>:</li>
</ul>
<pre><code>ABNF:
TypeName = UC *63("-" / Sys / UC / LC / DIGIT) ; PascalCase / Train-Case, 1-64 characters
FieldName = LC *63("_" / UC / LC / DIGIT) ; camelCase / snake_case, 1-64 characters
NSID = (UC / LC) *7(UC / LC / DIGIT) ; Namespace ID, length = 1-8 characters
TypeRef = [NSID ":"] TypeName ; Reference to a defined type with optional namespace prefix
Sys = "$" ; 'DOLLAR SIGN', Used in tool-generated type names, e.g., Color$values.
UC = %x41-5A ; A-Z
LC = %x61-7A ; a-z
DIGIT = %x30-39 ; 0-9
Regular Expression:
TypeName: ^[A-Z][-$A-Za-z0-9]{0,63}$
FieldName: ^[a-z][_A-Za-z0-9]{0,63}$
NSID: ^[A-Za-z][A-Za-z0-9]{0,7}$
</code></pre>
<h6 id="figure-3-1-jadn-default-name-syntax-in-abnf-and-regular-expression-formats">Figure 3-1: JADN Default Name Syntax in ABNF and Regular Expression Formats</h6>
<p>Specifications MAY use the same syntax for TypeName and FieldName. Using distinct formats may aid understanding but does not affect the meaning of type definitions.</p>
<h3 id="313-upper-bounds">3.1.3 Upper Bounds</h3>
<p>Type definitions for variable-length types may include maximum size limits using the <em>maxv</em> option defined in <a href="#321-type-options">Section 3.2.1</a>. If an individual type does not define an explicit limit, it uses the limit shown in the package's $MaxBinary, $MaxString, or $MaxElements configuration variable (<a href="#6-schema-packages">Section 6</a>). If the specification does not define a limit, the definition defaults to the values shown here, which are deliberately conservative to encourage specification authors to define limits based on application requirements.</p>
<ul>
<li>JADN specifications SHOULD define size limits on the variable-length types shown in Figure 3-2.</li>
<li>Specifications that do not define alternate size limits SHOULD use the limits shown in Figure 3-2.</li>
</ul>
<pre><code>Type Name Limit Description
----- ----- ----- -----------
Binary $MaxBinary 255 Maximum number of octets
String $MaxString 255 Maximum number of characters
Array, ArrayOf, $MaxElements 100 Maximum number of items/properties
Map, MapOf, Record
</code></pre>
<h6 id="figure-3-2-jadn-default-size-limits">Figure 3-2: JADN Default Size Limits</h6>
<h3 id="314-descriptions">3.1.4 Descriptions</h3>
<p>Description elements (TypeDescription, ItemDescription and FieldDescription) are reserved for comments from schema authors to readers or maintainers of the schema.</p>
<ul>
<li>The description value MUST be a string, which MAY be empty.</li>
<li>Implementations MUST NOT present this string to end users.</li>
<li>Tools for editing schemas SHOULD support displaying and editing descriptions.</li>
<li>Implementations MUST NOT take any other action based on the presence, absence, or content of description values.</li>
</ul>
<p>Description values MAY be used in debug or error output which is intended for developers making use of schemas. Tools that translate other media types or programming languages to and from a JADN schema MAY choose to convert that media type or programming language's native comments to or from description values. Implementations MAY strip description values at any point during processing.</p>
<h2 id="32-options">3.2 Options</h2>
<p>This section defines the mechanism used to support a varied set of information needs within the strictly regular structure of <a href="#31-type-definitions">Section 3.1</a>. New requirements can be accommodated by defining new options without modifying that structure. Type and Field options are classifiers that, along with the base type, determine whether data values are instances of the defined type.</p>
<p>Each option is a text string that may be included in TypeOptions or FieldOptions, encoded as follows:</p>
<ul>
<li>The first character is the option ID. Its Unicode codepoint is the numeric value (FieldID) shown in <a href="#321-type-options">Section 3.2.1</a> and <a href="#322-field-options">Section 3.2.2</a>.</li>
<li>The remaining characters are the option value. Boolean options have no additional characters; if the option ID is present the value of that option is True.</li>
</ul>
<h3 id="321-type-options">3.2.1 Type Options</h3>
<p>Type options apply to the type definition as a whole. The <em>id</em>, <em>vtype</em>, <em>ktype</em>, <em>enum</em>, and <em>pointer</em> options are intrinsic components of the types to which they apply. Other options specify value constraints on the type.</p>
<pre><code>TypeOption = Choice
61 id Boolean // '=' Items and Fields are denoted by FieldID rather than FieldName (Section 3.2.1.1)
42 vtype String // '*' Value type for ArrayOf and MapOf (Section 3.2.1.2)
43 ktype String // '+' Key type for MapOf (Section 3.2.1.3)
35 enum String // '#' Extension: Enumerated type derived from a specified type (Section 3.3.3)
62 pointer String // '>' Extension: Enumerated type pointers derived from a specified type (Section 3.3.5)
47 format String // '/' Semantic validation keyword (Section 3.2.1.5)
37 pattern String // '%' Regular expression used to validate a String type (Section 3.2.1.6)
121 minf Number // 'y' Minimum real number value (Section 3.2.1.7)
122 maxf Number // 'z' Maximum real number value
123 minv Integer // '{' Minimum integer value, octet or character count, or element count (Section 3.2.1.7)
125 maxv Integer // '}' Maximum integer value, octet or character count, or element count
113 unique Boolean // 'q' ArrayOf instance must not contain duplicate values (Section 3.2.1.8)
115 set Boolean // 's' ArrayOf instance is unordered and unique (Section 3.2.1.9)
98 unordered Boolean // 'b' ArrayOf instance is unordered (Section 3.2.1.10)
88 extend Boolean // 'X' Type is extensible; new Items or Fields may be appended (Section 3.2.1.11)
33 default String // '!' Default value (Section 3.2.1.12)
</code></pre>
<ul>
<li>TypeOptions MUST contain zero or one instance of each TypeOption.</li>
<li>TypeOptions MUST contain only TypeOption instances allowed for BaseType as shown in Table 3-3, plus a default value.</li>
<li>If BaseType is ArrayOf, TypeOptions MUST include the <em>vtype</em> option and MUST NOT include more than one collection option (<em>set</em>, <em>unique</em>, or <em>unordered</em>).</li>
<li>If BaseType is MapOf, TypeOptions MUST include <em>ktype</em> and <em>vtype</em> options.</li>
</ul>
<h6 id="table-3-3-allowed-options">Table 3-3. Allowed Options</h6>
<table>
<thead>
<tr class="header">
<th style="text-align: left;">BaseType</th>
<th style="text-align: left;">Allowed Options</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: left;">Binary</td>
<td style="text-align: left;">minv, maxv, format</td>
</tr>
<tr class="even">
<td style="text-align: left;">Boolean</td>
<td style="text-align: left;"></td>
</tr>
<tr class="odd">
<td style="text-align: left;">Integer</td>
<td style="text-align: left;">minv, maxv, format</td>
</tr>
<tr class="even">
<td style="text-align: left;">Number</td>
<td style="text-align: left;">minf, maxf, format</td>
</tr>
<tr class="odd">
<td style="text-align: left;">String</td>
<td style="text-align: left;">minv, maxv, format, pattern</td>
</tr>
<tr class="even">
<td style="text-align: left;">Enumerated</td>
<td style="text-align: left;">id, enum, pointer, extend</td>
</tr>
<tr class="odd">
<td style="text-align: left;">Choice</td>
<td style="text-align: left;">id, extend</td>
</tr>
<tr class="even">
<td style="text-align: left;">Array</td>
<td style="text-align: left;">extend, format, minv, maxv</td>
</tr>
<tr class="odd">
<td style="text-align: left;">ArrayOf</td>
<td style="text-align: left;">vtype, minv, maxv, unique, set, unordered</td>
</tr>
<tr class="even">
<td style="text-align: left;">Map</td>
<td style="text-align: left;">id, extend, minv, maxv</td>
</tr>
<tr class="odd">
<td style="text-align: left;">MapOf</td>
<td style="text-align: left;">vtype, ktype, minv, maxv</td>
</tr>
<tr class="even">
<td style="text-align: left;">Record</td>
<td style="text-align: left;">extend, minv, maxv</td>
</tr>
</tbody>
</table>
<h4 id="3211-field-identifiers">3.2.1.1 Field Identifiers</h4>
<p>The <em>id</em> option used with Enumerated, Choice, and Map types determines how fields are specified in API instances of these types. If the <em>id</em> option is absent, API instances use the FieldName string and the type is referred to as "named". If the <em>id</em> option is present, API instances use the FieldID tag and the type is referred to as "labeled". The Record type is always named and has no <em>id</em> option; the Array type is its labeled equivalent.</p>
<ul>
<li>In named types, FieldName is a defined name that is included in the semantics of the type, must be populated in the type definition, and may appear in serialized data depending on serialization format.</li>
<li>In labeled types, FieldName is a suggested label that is not included in the semantics of the type, may be empty in the type definition, and never appears in serialized data regardless of data format.</li>
</ul>
<p>For example an Enumerated list of HTTP status codes could include the field [403, "Forbidden"]. If the type definition does not include an <em>id</em> option, the API value is "Forbidden" and serialization rules determine whether FieldID or FieldName is used in serialized data. With the <em>id</em> option the API and serialized values are always the FieldID 403. The label "Forbidden" may be displayed in messages or user interfaces, as could customized labels such as "NotAllowed", "Verboten", or "Interdit".</p>
<h4 id="3212-value-type">3.2.1.2 Value Type</h4>
<p>The <em>vtype</em> option specifies the type of each field in an ArrayOf or MapOf type. It may be any JADN type or Defined type.</p>
<ul>
<li>An ArrayOf or MapOf instance MUST be considered invalid if any of its elements is not an instance of <em>vtype</em>.</li>
</ul>
<h4 id="3213-key-type">3.2.1.3 Key Type</h4>
<p>The <em>ktype</em> option specifies the type of each key in a MapOf type.</p>
<ul>
<li><em>ktype</em> SHOULD be a Defined type, either an enumeration or a type with constraints such as a pattern or semantic valuation keyword that specify a fixed subset of values that belong to a category.</li>
<li>A MapOf instance MUST be considered invalid if any of its keys is not an instance of <em>ktype</em>.</li>
</ul>
<h4 id="3214-derived-enumeration">3.2.1.4 Derived Enumeration</h4>
<p>The <em>enum</em> (<a href="#333-derived-enumerations">Section 3.3.3</a>) and <em>pointer</em> (<a href="#335-pointers">Section 3.3.5</a>) options are extensions that create an Enumerated type derived from a referenced Array, Choice, Map or Record type.</p>
<h4 id="3215-semantic-validation">3.2.1.5 Semantic Validation</h4>
<p>The <em>format</em> option value is a semantic validation keyword. Each keyword specifies validation requirements for a fixed subset of values that are accurately described by authoritative resources. The <em>format</em> option may also affect how values are serialized, see <a href="#4-serialization">Section 4</a>.</p>
<h6 id="table-3-4-semantic-validation-keywords">Table 3-4. Semantic Validation Keywords</h6>
<table>
<thead>
<tr class="header">
<th>Keyword</th>
<th>Type</th>
<th>Requirement</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>JSON Schema formats</td>
<td>String</td>
<td>All semantic validation keywords defined in Section 7.3 of <a href="#jsonschema">JSON Schema</a>.</td>
</tr>
<tr class="even">
<td>eui</td>
<td>Binary</td>
<td>IEEE Extended Unique Identifier (MAC Address), EUI-48 or EUI-64 as specified in <a href="#eui">EUI</a></td>
</tr>
<tr class="odd">
<td>ipv4-addr</td>
<td>Binary</td>
<td>IPv4 address as specified in <a href="#rfc791">RFC 791</a> Section 3.1</td>
</tr>
<tr class="even">
<td>ipv6-addr</td>
<td>Binary</td>
<td>IPv6 address as specified in <a href="#rfc8200">RFC 8200</a> Section 3</td>
</tr>
<tr class="odd">
<td>ipv4-net</td>
<td>Array</td>
<td>Binary IPv4 address and Integer prefix length as specified in <a href="#rfc4632">RFC 4632</a> Section 3.1</td>
</tr>
<tr class="even">
<td>ipv6-net</td>
<td>Array</td>
<td>Binary IPv6 address and Integer prefix length as specified in <a href="#rfc4291">RFC 4291</a> Section 2.3</td>
</tr>
<tr class="odd">
<td>i8</td>
<td>Integer</td>
<td>Signed 8 bit integer, value must be between -128 and 127.</td>
</tr>
<tr class="even">
<td>i16</td>
<td>Integer</td>
<td>Signed 16 bit integer, value must be between -32768 and 32767.</td>
</tr>
<tr class="odd">
<td>i32</td>
<td>Integer</td>
<td>Signed 32 bit integer, value must be between -2147483648 and 2147483647.</td>
</tr>
<tr class="even">
<td>u<<em>n</em>></td>
<td>Integer</td>
<td>Unsigned integer or bit field of <<em>n</em>> bits, value must be between 0 and 2^<<em>n</em>> - 1.</td>
</tr>
</tbody>
</table>
<h4 id="3216-pattern">3.2.1.6 Pattern</h4>
<p>The <em>pattern</em> option specifies a regular expression used to validate a String instance.</p>
<ul>
<li>The <em>pattern</em> value SHOULD conform to the Pattern grammar of <a href="#es9">ECMAScript</a> Section 21.2.</li>
<li>A String instance MUST be considered invalid if it does not match the regular expression specified by <em>pattern</em>.</li>
</ul>
<h4 id="3217-size-and-value-constraints">3.2.1.7 Size and Value Constraints</h4>
<p>The <em>minv</em> and <em>maxv</em> options specify size or integer value limits. The <em>minf</em> and <em>maxf</em> options specify real number value limits.</p>
<ul>
<li>For Binary, String, Array, ArrayOf, Map, MapOf, and Record types:
<ul>
<li>if <em>minv</em> is not present, it defaults to zero.</li>
<li>if <em>maxv</em> is not present or is zero, it defaults to the upper bound specified in <a href="#313-upper-bounds">Section 3.1.3</a>.</li>
<li>a Binary instance MUST be considered invalid if its number of bytes is less than <em>minv</em> or greater than <em>maxv</em>.</li>
<li>a String instance MUST be considered invalid if its number of characters is less than <em>minv</em> or greater than <em>maxv</em>.</li>
<li>an Array, ArrayOf, Map, MapOf, or Record instance MUST be considered invalid if its number of elements is less than <em>minv</em> or greater than <em>maxv</em>.</li>
</ul></li>
<li>For Integer types:
<ul>
<li>if <em>minv</em> is present, an instance MUST be considered invalid if its value is less than <em>minv</em>.</li>
<li>if <em>maxv</em> is present, an instance MUST be considered invalid if its value is greater than <em>maxv</em>.</li>
</ul></li>
<li>For Number types:
<ul>
<li>if <em>minf</em> is present, an instance MUST be considered invalid if its value is less than <em>minf</em>.</li>
<li>if <em>maxf</em> is present, an instance MUST be considered invalid if its value is greater than <em>maxf</em>.</li>
</ul></li>
</ul>
<h4 id="3218-unique-values">3.2.1.8 Unique Values</h4>
<p>The <em>unique</em> option specifies that values in an array must not be repeated.</p>
<ul>
<li>For the ArrayOf type, if <em>unique</em> is present an instance MUST be considered invalid if it contains duplicate values.</li>
</ul>
<h4 id="3219-set">3.2.1.9 Set</h4>
<p>The <em>set</em> option specifies that an ArrayOf type is unordered and unique.</p>
<ul>
<li>For the ArrayOf type, if <em>set</em> is present an instance MUST be considered invalid if it contains duplicate values.</li>
</ul>
<h4 id="32110-unordered">3.2.1.10 Unordered</h4>
<p>The <em>unordered</em> option specifies that an ArrayOf type may contain duplicate values and that its values have no defined order. Because values cannot be selected by value or position, it has the semantics of a "bag" or "urn" from which elements are picked at random.</p>
<h4 id="32111-extension-point">3.2.1.11 Extension Point</h4>
<p>The <em>extend</em> option is an assertion that an Enumerated, Choice, Array, Map or Record type MAY be incomplete and that future versions MAY add new fields that do not change the definitions of existing fields. This option does not affect the validity of data with respect to a specific schema, it is an indicator that applications may be able to obtain a newer version of the same package for which the data is valid. Types without this option assert that the package identifier will be changed if any field is added, modified, or deleted.</p>
<h4 id="32112-default-value">3.2.1.12 Default Value</h4>
<p>The <em>default</em> option specifies the initial or default value of a field. Applications deserializing a document MUST initialize an unspecified type with its default value. Serialization behavior is not defined; applications MAY omit or populate fields whose values equal the default.</p>
<h3 id="322-field-options">3.2.2 Field Options</h3>
<p>Field options may be specified for each field within a structured type definition.</p>
<pre><code>FieldOption = Choice
91 minc Integer // '[' Minimum cardinality, default = 1, 0 = optional (Section 3.2.2.1)
93 maxc Integer // ']' Maximum cardinality, default = 1, 0 = default max, >1 = array
38 tagid Enumerated // '&' Field containing an explicit tag for this Choice type (Section 3.2.2.2)
60 dir Boolean // '<' Pointer enumeration treats field as a group of items (Extension: Section 3.3.5)
75 key Boolean // 'K' Field is a primary key for this type (Extension: Section 3.3.6)
76 link Boolean // 'L' Field is a foreign key reference to a type instance (Extension: Section 3.3.6)
</code></pre>
<ul>
<li>FieldOptions MUST NOT include more than one of each option.</li>
<li>All TypeOption values (<a href="#321-type-options">Section 3.2.1</a>) included in FieldOptions are extensions. Each TypeOption MUST apply to FieldType as defined in <a href="#table-3-3-allowed-options">Table 3-3</a>.</li>
</ul>
<h4 id="3221-multiplicity">3.2.2.1 Multiplicity</h4>
<p>Cardinality is the number of elements in a group, and multiplicity is the range of allowed cardinalities for that group. The <em>minc</em> and <em>maxc</em> options specify the minimum and maximum cardinality in a field of an Array, Choice, Map, or Record type:</p>
<table>
<thead>
<tr class="header">
<th style="text-align: right;">minc</th>
<th style="text-align: right;">maxc</th>
<th style="text-align: right;">Multiplicity</th>
<th style="text-align: left;">Description</th>
<th style="text-align: left;">Keywords</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: right;">0</td>
<td style="text-align: right;">1</td>
<td style="text-align: right;">0..1</td>
<td style="text-align: left;">No instances or one instance</td>
<td style="text-align: left;">optional</td>
</tr>
<tr class="even">
<td style="text-align: right;">1</td>
<td style="text-align: right;">1</td>
<td style="text-align: right;">1</td>
<td style="text-align: left;">Exactly one instance</td>
<td style="text-align: left;">required</td>
</tr>
<tr class="odd">
<td style="text-align: right;">0</td>
<td style="text-align: right;">0</td>
<td style="text-align: right;">0..*</td>
<td style="text-align: left;">Zero or more instances</td>
<td style="text-align: left;">optional, repeated</td>
</tr>
<tr class="even">
<td style="text-align: right;">1</td>
<td style="text-align: right;">0</td>
<td style="text-align: right;">1..*</td>
<td style="text-align: left;">At least one instance</td>
<td style="text-align: left;">required, repeated</td>
</tr>
<tr class="odd">
<td style="text-align: right;">m</td>
<td style="text-align: right;">n</td>
<td style="text-align: right;">m..n</td>
<td style="text-align: left;">At least m but no more than n instances</td>
<td style="text-align: left;">required, repeated</td>
</tr>
</tbody>
</table>
<ul>
<li>if <em>minc</em> is not present, it defaults to 1.</li>
<li>if <em>maxc</em> is not present, it defaults to the greater of 1 or <em>minc</em>.</li>
<li>if <em>maxc</em> is 0, it defaults to the MaxElements upper bound specified in <a href="#313-upper-bounds">Section 3.1.3</a>.</li>
<li>if <em>maxc</em> is less than <em>minc</em>, the field definition MUST be considered invalid.</li>
</ul>
<p>If <em>minc</em> is 0, the field is optional, otherwise it is required.<br />
If <em>maxc</em> is 1 the field is a single element, otherwise it is an array of elements as described in <a href="#332-field-multiplicity">Section 3.3.2</a>.</p>
<p>Within a Choice type <em>minc</em> values of 0 and 1 are equivalent because all fields are optional and exactly one must be present. Values greater than 1 specify an array of elements.</p>
<h4 id="3222-discriminated-union-with-explicit-tag">3.2.2.2 Discriminated Union with Explicit Tag</h4>
<p>The Choice type represents a <a href="#union">Discriminated Union</a>, a data structure that could take on several different, but fixed, types. By default a Choice is a Map with exactly one key-value pair, where the key determines the value type. But if the <em>tagid</em> option is present on a Choice field in an Array or Record container, it indicates that a separate Tag field within that container determines the value type.</p>
<ul>
<li>The Tag field MUST be an Enumerated type derived from the Choice. It MAY contain a subset of fields from the Choice.</li>
</ul>
<p><strong>Example:</strong></p>
<pre><code>Product = Choice // Discriminated union
1 furniture Furniture
2 appliance Appliance
3 software Software
Dept = Enumerated // Explicit Tag values derived from the Choice
1 furniture
2 appliance
3 software
Software = String /uri
Stock1 = Record // Discriminated union with intrinsic tag
1 quantity Integer
2 product Product // Value = Map with one key/value
Stock2 = Record // Container with explicitly-tagged discriminated union
1 dept Dept // Tag = one key from Choice
2 quantity Integer
3 product Product(TagId[dept]) // Choice specifying an explicit tag field
</code></pre>
<p>Example JSON serializations of these types are:</p>
<p>Stock1 - Choice with intrinsic tag:</p>
<pre><code>{
"quantity": 395,
"product": {"software": "http://www.example.com/B902D1P0W37"}
}
</code></pre>
<p>Stock2 - Choice with explicit tag:</p>
<pre><code>{
"dept": "software",
"quantity": 395,
"product": "http://www.example.com/B902D1P0W37"
}
</code></pre>
<p><strong>Intrinsic tags:</strong></p>
<p>When discriminated unions are grouped the distinction between intrinsic and explicit tags becomes more apparent. A collection with intrinsic tags is simply a Map, which results in what the <a href="#transform">W3C JSON and XML Transformations Workshop</a> called "Friendly" encodings.</p>
<pre><code> Hashes = Map{1..*} // Multiple discriminated unions with intrinsic tag is a Map
1 md5 Binary{16..16} /x optional
2 sha1 Binary{20..20} /x optional
3 sha256 Binary{32..32} /x optional
</code></pre>
<p>Hashes Example:</p>
<div class="sourceCode" id="cb13"><pre class="sourceCode json"><code class="sourceCode json"><a class="sourceLine" id="cb13-1" title="1"><span class="fu">{</span></a>
<a class="sourceLine" id="cb13-2" title="2"> <span class="dt">"sha256"</span><span class="fu">:</span> <span class="st">"C9004978CF5ADA526622ACD4EFED005A980058B7B9972B12F9B3A5D0DA46B7D9"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb13-3" title="3"> <span class="dt">"md5"</span><span class="fu">:</span> <span class="st">"B64CF5EAF07E86D1697D4EEE96A670B6"</span></a>
<a class="sourceLine" id="cb13-4" title="4"><span class="fu">}</span></a></code></pre></div>
<p><strong>Explicit tags:</strong></p>
<p>A collection with explicit tags is an array of tag-value pairs. It is more complex to specify, and it results in "UnFriendly" encodings with repeated tag and value keys. Yet because some specifications are written in this style, the <em>tagid</em> option exists to designate an explicit field to be used to specify the value type.</p>
<pre><code> Hashes2 = ArrayOf(HashVal) // Multiple discriminated unions with explicit tags is an Array
HashVal = Record
1 algorithm Enumerated(Enum[HashAlg]) // Tag - one key from Choice
2 value HashAlg(TagId[algorithm]) // Value selected from Choice by 'algorithm' field
HashAlg = Choice
1 md5 Binary{16..16} /x
2 sha1 Binary{20..20} /x
3 sha256 Binary{32..32} /x
</code></pre>
<p>Hashes2 Example:</p>
<div class="sourceCode" id="cb15"><pre class="sourceCode json"><code class="sourceCode json"><a class="sourceLine" id="cb15-1" title="1"><span class="ot">[</span></a>
<a class="sourceLine" id="cb15-2" title="2"> <span class="fu">{</span></a>
<a class="sourceLine" id="cb15-3" title="3"> <span class="dt">"algorithm"</span><span class="fu">:</span> <span class="st">"md5"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb15-4" title="4"> <span class="dt">"value"</span><span class="fu">:</span> <span class="st">"B64CF5EAF07E86D1697D4EEE96A670B6"</span></a>
<a class="sourceLine" id="cb15-5" title="5"> <span class="fu">}</span><span class="ot">,</span><span class="fu">{</span></a>
<a class="sourceLine" id="cb15-6" title="6"> <span class="dt">"algorithm"</span><span class="fu">:</span> <span class="st">"sha256"</span><span class="fu">,</span></a>
<a class="sourceLine" id="cb15-7" title="7"> <span class="dt">"value"</span><span class="fu">:</span> <span class="st">"C9004978CF5ADA526622ACD4EFED005A980058B7B9972B12F9B3A5D0DA46B7D9"</span></a>
<a class="sourceLine" id="cb15-8" title="8"> <span class="fu">}</span></a>
<a class="sourceLine" id="cb15-9" title="9"><span class="ot">]</span></a></code></pre></div>
<h2 id="33-jadn-extensions">3.3 JADN Extensions</h2>
<p>JADN consists of a set of core definition elements, plus several extensions that make type definitions more compact or support the <a href="#dry">DRY</a> software design principle. Extensions are syntactic sugar that can be replaced by core definitions without changing their meaning. Unfolding definitions into core format simplifies the code needed to serialize and validate data and may clarify their meaning, but creates additional definitions that must be kept in sync.</p>
<p>The following extensions can be converted to core definitions:</p>
<ul>
<li>Anonymous type definition within a field</li>
<li>Field multiplicity other than required/optional</li>
<li>Derived enumeration</li>
<li>MapOf type with Enumerated key type</li>
<li>Pointers</li>
<li>Links</li>
</ul>
<h3 id="331-type-definition-within-fields">3.3.1 Type Definition Within Fields</h3>
<p>A type without fields (Primitive types, ArrayOf, MapOf) may be defined anonymously within a field of a structure definition. Unfolding converts all anonymous type definitions to explicit named types and excludes all TypeOption values (<a href="#321-type-options">Section 3.2.1</a>) from FieldOptions.</p>
<p>Example:</p>
<pre><code>Member = Record
1 name String
2 email String /email
</code></pre>
<p>Unfolding replaces this with:</p>