docs: add explicit anchors

docs/meta-model/index.org

@@ -11,7 +11,6 @@
 
 #+BEGIN_SRC emacs-lisp :exports none
 (require 'ob-plantuml) ;; builtin
-(setq org-confirm-babel-evaluate nil)
 #+END_SRC
 
 #+BEGIN_ABSTRACT

docs/primer/index.org

@@ -14,7 +14,6 @@
 #+BEGIN_SRC emacs-lisp :exports none
 (require 'ob-dot) ;; builtin
 (require 'ob-sdml)
-(setq org-confirm-babel-evaluate nil)
 #+END_SRC
 
 #+NAME: img:sdml-logo
@@ -201,7 +200,7 @@ item or the same kind of item from /different manufacturers/.
 
 When we look at the italic text above we note the possible entities Kind, Variation, Size, Color, and Manufacturer.
 However, as we talk them through with the stakeholders we feel that they do not meet the criteria outlined in the
-section [[#where-to-start][Where do I start?]], except ~Manufacturer~.
+section [[#primer:where-to-start][Where do I start?]], except ~Manufacturer~.
 
 #+NAME: src:initial-retail-entities
 #+CAPTION: Initial Retail Entities
@@ -682,7 +681,7 @@ end
 #+END_SRC
 
 While this module has added a lot of detail, one structure at the end, ~PaymentInstrument~ is not yet complete. Be
-patient, we will come back to that in the section [[#add-unions]] later.
+patient, we will come back to that in the section [[#primer:add-unions]] later.
 
 #+BEGIN_ADVNOTE
 You can add a specific type of annotation, a constraint, to capture conditions that cannot be expressed by the model's
@@ -841,7 +840,7 @@ end
 #+END_SRC
 
 You will probably be thinking that all this detail is making the module quite large and possibly cumbersome. In the
-following section ([[#add-events]]) we will discuss approaches to organizing modules to allow not only ease of navigation
+following section ([[#primer:add-events]]) we will discuss approaches to organizing modules to allow not only ease of navigation
 but also parallel editing.
 
 #+BEGIN_ADVNOTE

docs/reference/complete-grammar.org

@@ -1,7 +1,10 @@
 #+LANGUAGE: en
 #+STARTUP: overview hidestars inlineimages entitiespretty
 
-* <<sec:complete-grammar>>Appendix: Surface Syntax Grammar
+* Appendix: Surface Syntax Grammar
+:PROPERTIES:
+:CUSTOM_ID: surface-syntax-grammar
+:END:
 
 The grammar of the surface syntax is presented in Extended Backus–Naur form (EBNF)[fn:ebnf]. The addition of a character literal
 range operation =..= reduces the number of single character alternatives for clarity. There are also a set of pre-defined
@@ -332,6 +335,9 @@ Whitespace
 #+END_SRC
 
 *** The Embedded Constraint Language
+:PROPERTIES:
+:CUSTOM_ID: ebnf:constraints
+:END:
 
 Given that the /formal/ constraint language component of SDML is likely to be used less frequently *and* the grammar is
 fairly long we have made it a separate section.
@@ -460,6 +466,9 @@ ReservedSelf
 #+END_SRC
 
 *** Constraint Environment Definitions
+:PROPERTIES:
+:CUSTOM_ID: ebnf:constraint-environments
+:END:
 
 #+BEGIN_SRC ebnf
 ConstraintEnvironment
@@ -502,6 +511,9 @@ ByDefinition
 #+END_SRC
 
 *** Sequence Builders
+:PROPERTIES:
+:CUSTOM_ID: ebnf:sequence-builders
+:END:
 
 #+BEGIN_SRC ebnf
 SequenceBuilder

docs/reference/constraint-semantics.org

@@ -1,7 +1,10 @@
 #+LANGUAGE: en
 #+STARTUP: overview hidestars inlineimages entitiespretty
 
-* <<app:constraint-semantics>>Appendix: Constraint Semantics
+* Appendix: Constraint Semantics
+:PROPERTIES:
+:CUSTOM_ID: constraint-semantics
+:END:
 
 The embedded constraint language is purely functional and constraint assertions MUST return a single boolean value
 determining correctness. The constraint language follows the naming convention of Common Logic, and so a constraint
@@ -73,6 +76,9 @@ Semantically, sentences are formulas that can be /true/ (⊤) or /false/ (⊥),
 occurrences of variables depends on the assignment of values to these variables.
 
 ** Simple Sentences
+:PROPERTIES:
+:CUSTOM_ID: csem:simple-sentences
+:END:
 
 An /atomic sentence/ takes the form of a predicate with a set of zero or more arguments.
 
@@ -100,6 +106,9 @@ lhs ≥ rhs
 #+END_EXAMPLE
 
 ** Boolean Sentences
+:PROPERTIES:
+:CUSTOM_ID: csem:boolean-sentences
+:END:
 
 The /negation/ of a sentence takes the form of a preceding logical /not/ operator.
 
@@ -157,6 +166,9 @@ L \iff R \equiv (L \implies R) \land (R \implies L)
 \end{equation}
 
 ** Quantified Sentences
+:PROPERTIES:
+:CUSTOM_ID: csem:quantified-sentences
+:END:
 
 The /universal quantification/ over a sequence says that "for all elements $e$ in the sequence $S$ the sentence $s$ must hold
 true".
@@ -175,6 +187,9 @@ exists e in Sequence s
 #+END_EXAMPLE
 
 ** Sequence Builders
+:PROPERTIES:
+:CUSTOM_ID: csem:sequence-builders
+:END:
 
 *Notation*
 
@@ -194,7 +209,7 @@ t ≔ \bigl\{ x_1, \cdots, x_n \mid \ldots \bigr\} \implies \forall x \in x_1, \
 \end{equation}
 
 #+BEGIN_COMMENT
-The expression from section [[sec:sequence-builders]] does not provide a domain for the variable $x$ and so will take on all
+The expression from the previous section does not provide a domain for the variable $x$ and so will take on all
 values from the domain of discourse, $\mathcal{D}$. We may then define a transform in the following manner.
 #+END_COMMENT
 
@@ -240,7 +255,9 @@ def constraints(anns - > {}  Annotation) -> {} Constraint
 #+END_EXAMPLE
 
 ** Quantified Sentences as Sequence Builders
-
+:PROPERTIES:
+:CUSTOM_ID: csem:quantified-sentences-as-sequence-builders
+:END:
 
 The existential qualifier specifically determines that there is /at least one/ element in the type or sequence where the
 sentence provided holds true. If you need to ensure a specific cardinality, for example that /exactly three/ elements in
@@ -276,7 +293,10 @@ is_empty({ e | e in Sequence not s}
 
 In this manner we can treat the quantified sentences as syntactic sugar over specific forms of sequence comprehensions.
 
-** <<app:common-logic>>Constraints to ISO/IEC Common Logic
+** Constraints to ISO/IEC Common Logic
+:PROPERTIES:
+:CUSTOM_ID: csem:common-logic
+:END:
 
 This appendix describes the *normative* mapping from SDML/Constraints to the ISO/IEC Common Logic standard.
 

docs/reference/constraints.org

@@ -1,7 +1,10 @@
 #+LANGUAGE: en
 #+STARTUP: overview hidestars inlineimages entitiespretty
 
-* <<sec:model-constraints>>Capturing Model Constraints
+* Capturing Model Constraints
+:PROPERTIES:
+:CUSTOM_ID: model-constraints
+:END:
 
 In developing any data, domain, or information  model there are certain constraints between model elements that are
 either difficult to represent in the model language itself. This is particularly true of visual languages or those with
@@ -36,6 +39,9 @@ end
 #+END_SRC
 
 ** Informal Constraints
+:PROPERTIES:
+:CUSTOM_ID: con:informal-constraints
+:END:
 
 Informal constraints, much like regular string values, have an optional language specifier. However, unlike regular
 strings this specifier has a more limited range as it's purpose is to identify a /controlled natural language/ used for
@@ -101,6 +107,9 @@ table [[tbl:informal-constraint-schemes]].
 | Common Logic Controlled English | ~CLCE~       |           | ISO Common Logic |
 
 ** Formal Constraints
+:PROPERTIES:
+:CUSTOM_ID: con:formal-constraints
+:END:
 
 Formal constraints have their own embedded constraint language whose semantics are a subset of ISO Common
 Logic[fn:isocl]. ISO Common Logic is most easily understood as an abstract language that allows for the interchange of
@@ -191,6 +200,9 @@ ConstraintSentence
 [[./ebnf-diagram/ConstraintSentence.svg]]
 
 *** Simple Sentences
+:PROPERTIES:
+:CUSTOM_ID: con:simple-sentences
+:END:
 
 #+BEGIN_SRC ebnf
 SimpleSentence
@@ -242,6 +254,9 @@ InequationRelation
 [[./ebnf-diagram/InequationRelation.svg]]
 
 *** Boolean Sentences
+:PROPERTIES:
+:CUSTOM_ID: con:boolean-sentences
+:END:
 
 Boolean sentences allow for the logical composition of sentences. 
 
@@ -303,6 +318,9 @@ BiconditionalOperator
 [[./ebnf-diagram/BiconditionalOperator.svg]]
 
 *** Quantified Sentences
+:PROPERTIES:
+:CUSTOM_ID: con:quantified-sentences
+:END:
 
 SDML supports, as shown in listing [[lst:ex-tagged-constraint-2]] sentences that range over values using the universal ($\forall$)
 or existential ($\exists$) quantifiers. A quantified sentence is therefore a sentence body with a set of variables bound to these
@@ -347,6 +365,9 @@ MembershipOperator
 [[./ebnf-diagram/MembershipOperator.svg]]
 
 *** Terms
+:PROPERTIES:
+:CUSTOM_ID: con:terms
+:END:
 
 #+BEGIN_SRC ebnf
 Term
@@ -408,7 +429,10 @@ ReservedSelf
     ::= "self"
 #+END_SRC
 
-*** <<sec:sequence-builders>>Sequence Builders
+*** Sequence Builders
+:PROPERTIES:
+:CUSTOM_ID: con:sequence-builders
+:END:
 
 A sequence builder uses /set-builder/ notation to allow both specific selection of elements from sequences and
 values from types. A sequence builder expression describes a sequence as a selection of values from existing sequences
@@ -464,6 +488,9 @@ SequenceBuilderBody
 [[./ebnf-diagram/SequenceBuilderBody.svg]]
 
 *** Constraint Environment
+:PROPERTIES:
+:CUSTOM_ID: con:constraint-environment
+:END:
 
 A formal constraint may start with an /environment/ that includes one or more /definitions/ that are then used in the
 constraint body. A definition introduces a new /function/ or /constant/ -- a constant is effectively a 0-arity function --
@@ -565,12 +592,18 @@ end
 #+END_SRC
 
 *** Optional Types
+:PROPERTIES:
+:CUSTOM_ID: con:optional-types
+:END:
 
 The introduction of optional types, that it a type name preceded by the operator "?" may be considered a convenience
 over the same type specified with a cardinality of ~{0..1}~. However, this greatly simplifies the implementation of
 constraints over possibly missing values.  
 
-** <<sec:type-classes>>Type Classes
+** Type Classes
+:PROPERTIES:
+:CUSTOM_ID: con:type-classes
+:END:
 
 TBD
 
@@ -582,6 +615,9 @@ TypeClassDef
 [[./ebnf-diagram/TypeClassDef.svg]]
 
 *** Type Parameters
+:PROPERTIES:
+:CUSTOM_ID: con:type-class-parameters
+:END:
 
 #+BEGIN_SRC ebnf
 TypeClassParameters
@@ -619,6 +655,9 @@ TypeClassBody
 [[./ebnf-diagram/TypeClassBody.svg]]
 
 *** Methods
+:PROPERTIES:
+:CUSTOM_ID: con:type-class-methods
+:END:
 
 #+BEGIN_SRC ebnf
 MethodDef
@@ -628,7 +667,9 @@ MethodDef
 [[./ebnf-diagram/MethodDef.svg]]
 
 *** Library Functions
-
+:PROPERTIES:
+:CUSTOM_ID: con:library-functions
+:END:
 
 #+BEGIN_EXAMPLE
 def predicate(Type) -> boolean