examples and todos loaded.

Signed-off-by: Darrell O'Donnell <darrell.odonnell@continuumloop.com>

package.json

@@ -55,6 +55,7 @@
     "merge-stream": "2.0.0",
     "pkg-dir": "4.2.0",
     "prismjs": ">=1.24.0",
+    "spec-up": "^0.10.6",
     "yargs": "16.2.0"
   }
 }

spec/clauses.md

@@ -4,6 +4,8 @@
 
 [//]: # (Main content {#sec:content})
 
+
+
 ## Executive Summary
 CoLorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Mi ipsum faucibus vitae aliquet nec ullamcorper sit amet. Scelerisque fermentum dui faucibus in ornare quam viverra orci. Maecenas ultricies mi eget mauris pharetra. Tempor nec feugiat nisl pretium fusce id. In ante metus dictum at tempor commodo ullamcorper a. Nulla at volutpat diam ut venenatis tellus in. 
 

spec/foreword.md

@@ -15,11 +15,12 @@ The mission of the Trust over IP (ToIP) Foundation is to define a complete archi
 
 Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.
 
-This document was prepared by the ToIP Technical Stack Working Group.
+This document was prepared by the ToIP Concepts & Terminology Working Group.
 
-Any feedback or questions on this document should be directed to https://github.com/trustoverip/specification/issues
+Any feedback or questions on this document should be directed to https://github.com/trustoverip/ctwg-main-glossary/issues
 
 THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. 
+
 IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 [//]: # (\newpage)

spec/header.md

@@ -1,10 +1,6 @@
 ## Status of This Memo
 
-This document contains a template specification for `ToIP`!.
-
-Information about the current status of this document, any errata,
-and how to provide feedback on it, may be obtained at
-[https://github.com/trustoverip/specification-template](https://github.com/trustoverip/specification-template).
+This is a VERY EARLY draft version of a ToIP Glossary, showing how `spec-up` can be used with relative ease.
 
 ## Copyright Notice
 
@@ -26,27 +22,3 @@ These materials are made available under and are subject to the [OWF CLA 1.0 - C
 
 THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. 
 IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-## RFC 2119
-The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and to ensure maximal efficiency in operation. IETF has been operating since the advent of the Internet using a Request for Comments (RFC) to convey “current best practice” to those organizations seeking its guidance for conformance purposes.
-
-The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements.  ToIP has adapted the IETF RFC 2119 for use in the <name of this document>, and therefore its applicable use in ToIP-compliant governance frameworks.
-
-The RFC 2119 keyword definitions and interpretation have been adopted. Those users who follow these guidelines SHOULD incorporate the following phrase near the beginning of their document:
-        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-
-RFC 2119 defines these keywords as follows:
-
- * MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
- * MUST NOT: This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.
- * SHOULD: This word, or the adjective "RECOMMENDED", means that there MAY exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course.
- * SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" means that there MAY exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood, and the case carefully weighed before implementing any behavior described with this label.
- * MAY: This word, or the adjective "OPTIONAL", means that an item is truly optional.  One vendor MAY choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor MAY omit the same item.
-
-Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119.
-
- * Mandatories are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
- * Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
- * Options are Requirements that use a MAY or OPTIONAL keyword.
-
-An implementation which does not include a particular option MUST be prepared to interoperate with other implementations which include the option, recognizing the potential for reduced functionality. As well, implementations which include a particular option MUST be prepared to interoperate with implementations which do not include the option and the subsequent lack of function the feature provides.

spec/introduction.md

@@ -9,4 +9,6 @@
 
 ## Introduction
 
-Fancy introduction!
+::: todo: Really Important
+  CTWG to create introduction. 
+:::

spec/normative_references.md

@@ -9,3 +9,23 @@
 [//]: # (ISO 32000-2, *Document management --- Portable Document Format --- Part 2: PDF 2.0*)
 
 [//]: # (:::)
+
+
+
+
+### Normative References
+[[spec-norm]]
+
+### Informative References
+
+[[spec-inform]]
+
+
+::: todo: Really Important
+  Adjust the placeholders below as they aren't currently used other than as an example.
+:::
+
+use `spec-up` constructs here:
+
+* `[[spec-inform:RFC3319]]` as example - will show above [[spec-inform:RFC3319]]
+* `[[spec-norm:DID-CORE]]` as example - will show above as we reference [[spec-norm:DID-CORE]]

spec/scope.md

@@ -7,4 +7,6 @@
 
 ## Scope
 
-Describe the scope
+::: todo: Really Important
+  CTWG to create Scope content. 
+:::

spec/terms_and_definitions.md

@@ -6,3 +6,51 @@
 [//]: # (blank)
 
 [//]: # (: file format defined by ISO 32000-2)
+
+
+## Terms & Definitions
+
+[[def: anonymous]]
+~ An adjective describing when the identity of a natural person or other actor is unknown.
+See also: pseudonym.
+
+[[def: assurance level]]
+~ A level of confidence that may be relied on by others. Different types of assurance levels are defined for different types of trust assurance mechanisms. Examples include authenticator assurance level, federation assurance level, and identity assurance level.
+
+[[def: authorization]]
+~ The process of verifying that a requested action or service is approved for a specific entity.
+Source: NIST-CSRC.
+* See also: [[ref: permission]].
+
+[[def: out-of-band introduction, OOBI]]
+~ A process by which two or more entities exchange VIDs in order to form a cryptographically verifiable connection (e.g., a ToIP connection), such as by scanning a QR code (in person or remotely) or clicking a deep link.
+* Also known as: [[ref:OOBI]].
+
+[[def: permission]]
+~ Authorization to perform some action on a system.
+* Source: [[ref: NIST-CSRC]].
+
+[[def: policy]]
+~ Statements, rules or assertions that specify the correct or expected behavior of an entity. 
+* Example: An authorization policy might specify the correct access control rules for a software component.
+* Source: [[ref: NIST-CSRC]]
+* See also: governance requirement, machine-readable policy.
+
+[[def: real world identity]]
+A term used to describe the opposite of digital identity, i.e., an identity (typically for a person) in the physical instead of the digital world.
+Also known as: RWI.
+See also: legal identity.
+
+[[def: self-certifying identifier, SCID]]
+* A subclass of verifiable identifier that is cryptographically verifiable without the need to rely on any third party for verification because the identifier is cryptographically bound to the cryptographic keys from which it was generated.
+* Also known as: autonomous identifier.
+
+## Sources for Terms & Definitions
+
+::: todo: Really Important
+  Add table of sources
+:::
+
+[def: NIST-CSRC]
+~ NIST Computer Security Resource Center Glossary
+* https://csrc.nist.gov/glossary/

spec/title.md

@@ -1,22 +1,26 @@
-ToIP Template Specification
+ToIP Main Glossary 
 ==================
 
-**Specification Status**: v1.0 Draft
+**Specification Status**: v0.0 Draft
 
 **Latest Draft:**
 
-[https://github.com/trustoverip/specification-template](https://github.com/trustoverip/specification-template)
+* [Github Repository](https://github.com/trustoverip/ctwg-main-glossary)
+* [Submit/View Issues](https://github.com/trustoverip/ctwg-main-glossary/issues)
+* other...
 
 **Editors:**
 
 - [Kevin Griffin](https://github.com/m00sey), [GLEIF](https://gleif.org)
 
 **Contributors:**
 
+- [Darrell O'Donnell](https://github.com/darrellodonnell), [Continuum Loop Inc.](https://www.continuumloop.com/)
+
 **Participate:**
 
-~ [GitHub repo](https://github.com/trustoverip/specification-template)
-~ [Commit history](https://github.com/trustoverip/specification-template/commits/main)
+~ [GitHub repo](https://github.com/trustoverip/ctwg-main-glossary)
+~ [Commit history](https://github.com/trustoverip/ctwg-main-glossary/commits/main)
 
 ------------------------------------
 

specs.json

@@ -2,7 +2,7 @@
 {
   "specs": [
     {
-      "title": "ToIP Template Specification",
+      "title": "ToIP Main Glossary v0.0",
       "spec_directory": "./spec",
       "output_path": "./docs",
       "markdown_paths": [