redactional changes

README.md

@@ -1,12 +1,8 @@
 # SAF Specification Source
+If you would like to read the System Architecture Framework (SAF) documentation, please visit [saf.gfse.org](https://saf.gfse.org)
 
-If you want to read the documentation of the System Architecture Framework (SAF), please head over to [saf.gfse.org](https://saf.gfse.org)
+We have changed the way the documentation is generated and github is now the source repository for an automatic document generation process. The main branch reflects the current state of development and will be updated as needed. The earlier SAF releases are still available in the legacy documentation format in separate branches:
 
-We have changed the way the documentation is generated, and this is now the source repository for the automatic document generation process.
-
-This is the main branch that reflects the current state of development and it is updated as required.
-
-The former SAF releases are still available, in the legacy documentation format in separate branches:
 * [Initial Release](https://github.com/GfSE/SAF-Specification/tree/Initial-Release/README.md)
 * [TdSE2022](https://github.com/GfSE/SAF-Specification/tree/TdSE2022/README.md)
 * [TdSE2023](https://github.com/GfSE/SAF-Specification/tree/TdSE2023/README.md)

src/CHANGES.md

@@ -1,5 +1,4 @@
-![System Architecture Framework](diagrams/Banner_SAF.png)
-# SAF User Documentation : Changes
+Changes
 |Date|Change|
 |--|--|
 |2024-10-27|Switch over to new documentation format.|

src/_sass/custom/custom.scss

@@ -1,18 +1,23 @@
 .side-bar {
-  width: 18rem;
+  width: 20rem;
  }
 
+ .site-nav {
+  width: 20rem;
+ }
+
+
 
  @media (min-width: 66.5rem) {
    .main {
-    margin-left: 18rem !important;
+    margin-left: 20rem !important;
     max-width: 80% !important;
   }
 }
 
 @media (min-width: 50rem) {
   .main {
-   margin-left: 18rem !important;
+   margin-left: 20rem !important;
    max-width: 80% !important;
  }
 }
@@ -97,6 +102,6 @@
 
 
 .plugin-version-menu-background-fonts-style {
-  @include fs-2;
+  @include fs-3;
   background-color: inherit;
 }

src/assets/js/plugin_versions_menu.js

@@ -117,7 +117,7 @@ function handleVersionedDocs(repository_nwo, basePath) {
             currentVersion = defaultBranch;
             currentPage = path.substring(basePath.length);
         }
-        menu.innerHTML = `SAF Version: ${currentVersion}`;
+        menu.innerHTML = `Branch: ${currentVersion}`;
         menu.appendChild(dropdown);
 
         options.push({text:'TdSE2023',value:'TdSE2023'})

src/devdoc/dev-cd.md

@@ -6,4 +6,4 @@ has_children: true
 nav_order: 30
 ---
 ## Development View on Common Domain
-This Versions of the Viewpoint documentation is intended for Framework Developers.
+This documentation is intended for Framework Developers.

src/devdoc/dev-domain.md

@@ -3,7 +3,7 @@ title: SAF Development Domain
 parent: "Developer Documentation"
 layout: default
 has_children: true
-nav_order: 30
+nav_order: 60
 ---
 ## Development Domain
 {% assign dom = site.data.domains | where: "Name","SAF Development" %}

src/devdoc/dev-fd.md

@@ -3,7 +3,7 @@ title: "Dev-View Functional Domain"
 parent: "Developer Documentation"
 layout: default
 has_children: true
-nav_order: 30
+nav_order: 40
 ---
 ## Development View on Functional Domain
-This Versions of the Viewpoint documentation is intended for Framework Developers.
+This documentation is intended for Framework Developers.

src/devdoc/dev-ld.md

@@ -3,7 +3,7 @@ title: "Dev-View Logical Domain"
 parent: "Developer Documentation"
 layout: default
 has_children: true
-nav_order: 30
+nav_order: 45
 ---
 ## Development View on Logical Domain
-This Versions of the Viewpoint documentation is intended for Framework Developers.
+This documentation is intended for Framework Developers.

src/devdoc/dev-od.md

@@ -3,7 +3,7 @@ title: "Dev-View Operational Domain"
 parent: "Developer Documentation"
 layout: default
 has_children: true
-nav_order: 30
+nav_order: 35
 ---
 ## Development View on Operational Domain
-This Versions of the Viewpoint documentation is intended for Framework Developers.
+This documentation is intended for Framework Developers.

src/devdoc/dev-pd.md

@@ -3,7 +3,7 @@ title: "Dev-View Physical Domain"
 parent: "Developer Documentation"
 layout: default
 has_children: true
-nav_order: 30
+nav_order: 50
 ---
 ## Development View on Physical Domain
-This Versions of the Viewpoint documentation is intended for Framework Developers.
+This documentation is intended for Framework Developers.

src/devdoc.md → src/devdoc/devdoc.md

@@ -1,7 +1,7 @@
 ---
 title: Developer Documentation
 layout: default
-nav_order: 40
+nav_order: 90
 ---
 # Developer Documentation
 
@@ -11,15 +11,15 @@ SAF is developed to foster Model Based Systems Engineering, and itself is develo
 
 ## Kinds of Models
 
-![Bild](./assets/images/Kinds-of-Models.svg)
+![Bild](../assets/images/Kinds-of-Models.svg)
 
 There are several kinds of models around SAF serving a certain purpose
 
 * **SAF System Model**
 
   This is a model dedicated to the development of one or more systems. It is a model that users of SAF create and maintain. It may be maintained in one of the Tools supported by a SAF Profile Model. The SAF example model SAF_FFDS.mdzip is a System Model.
 * **SAF_Profile Model**
-  This is a model needed to create a SAF System Model. It is tool specific and (hopefully) compliant to the SAF Specification.  There currently several contributed models. Some of the Repositories also contain an example System Model. Please head over to [Tool Implementations](index.md#tool-implementations).
+  This is a model needed to create a SAF System Model. It is tool specific and (hopefully) compliant to the SAF Specification.  There currently several contributed models. Some of the Repositories also contain an example System Model. Please head over to [Tool Implementations](../index.md#tool-implementations).
 
 
 
@@ -35,7 +35,7 @@ The conceptual model is the foundation of SAF development.
 It governs, which items SAF consist of and how these items are related.
 It follows the concepts of ISO 42010. SAF extends ISO 42010 in a way that SAF is able to express a rationale for a Stakeholders Concern.
 
-![Bild](./assets/images/Concept-Model-Definition.svg)
+![Bild](../assets/images/Concept-Model-Definition.svg)
 ### Core Concepts
 Within the conceptual model the following elements can be recognized (many of them are specializations of ISO 42010 Concepts):
 
@@ -57,7 +57,7 @@ select a set of SAF Concepts in order to adress the information need expressed b
   They also could be used to plan work items in order to plan a MBSE effort.
   The goal is, to precisely define the needed model work for certain points in an engieering project.
 
-Details are documented in the [metamodeling guide](devdoc/metamodel-guideline/modelguideline.md).
+Details are documented in the [metamodeling guide](metamodel-guideline/modelguideline.md).
 
 
 [^1]: The question about the recommended workflow cannot be answered by a single viewpoint description, this is an overarcing topic, which is currently not covered by the SAF documentation. [See issue 14](https://github.com/GfSE/SAF-Specification/issues/14)

src/devdoc/icons/readme.md

@@ -2,7 +2,7 @@
 parent: Developer Documentation
 title: Icons
 layout: default
-nav_order: 40
+nav_order: 70
 ---
 Note, that the definition of icons is work in progress.
 

src/index.md

@@ -18,7 +18,7 @@ The SAF can be used stand-alone and also complementary to enterprise architectur
 
 # SAF Documentation
 
-This site contains both documentation for users of SAF and developers of SAF. To understand how to use SAF, head over to **[Using SAF](using.md)**. To understand how we develop SAF, see **[Development Documentation](devdoc.md)**. We always welcome contributions from our MBSE community to improve SAF, see [how to contribute to SAF](contributing.md).
+This site contains both documentation for users of SAF and developers of SAF. To understand how to use SAF, head over to [Using SAF](./userdoc/using.md). To understand how we develop SAF, see [Development Documentation](./devdoc/devdoc.md). We always welcome contributions from our MBSE community to improve SAF, see [how to contribute](./userdoc/contributing.md).
 
 # Example
 The System Architecture Framework Specification application is demonstrated using the **Fire Forest Detection System (FFDS)** example, courtesy of Tim Weilkiens. The Fire Forest Detection System example is based on the publication **SYSMOD - The Systems Modeling Toolbox, 3rd edition Pragmatic MBSE with SysML, Tim Weilkiens**

src/userdoc/concerns.html

@@ -7,7 +7,7 @@
 ---
 <h1> Viewpoint Concerns</h1>
 <div >
-<a href="../faq.html#concerns">Concerns</a> are the information needs of <a href="../faq.html#stakeholders">Stakeholders</a>. They should be justified by a rationale. Concerns are addressed by <a href="../faq.html#viewpoints">viewpoints</a>.
+<a href="faq.html#concerns">Concerns</a> are the information needs of <a href="faq.html#stakeholders">Stakeholders</a>. They should be justified by a rationale. Concerns are addressed by <a href="faq.html#viewpoints">viewpoints</a>.
 </div>
 <table>
 

src/contributing.md → src/userdoc/contributing.md

@@ -1,7 +1,7 @@
 ---
 title: Contributing
 layout: default
-nav_order: 90
+nav_order: 80
 ---
 # How To Contribute to SAF?
 
@@ -25,4 +25,4 @@ Changes may be proposed using the Discussions on the Specification Repository
 
 ## Developing SAF
 
-he development of the SAF viewpoints comprises several interlinked elements and concepts. How the SAF is developed is explained in more detail in this article [SAF-Development](developing-saf/development.md). 
+he development of the SAF viewpoints comprises several interlinked elements and concepts. How the SAF is developed is explained in more detail in this article [SAF-Development](../devdoc/devdoc.md). 

src/faq.md → src/userdoc/faq.md

@@ -1,7 +1,7 @@
 ---
 title: FAQ
 layout: default
-nav_order: 99
+nav_order: 70
 ---
 # Frequently Asked Questions
 ## Viewpoints
@@ -14,14 +14,14 @@ The elements and relationships don't change if they are captured in Models - MBS
 
 *The Viewpoint Concept is layed out in ISO 42010*
 
-See the [SAF Viewpoint documentation](./userdoc/viewpoints.md).
+See the [SAF Viewpoint documentation](viewpoints.md).
 
 ## Stakeholders
 **What are Stakeholders?** 
 There are two classes of Stakeholders in SAF. **System Stakeholders** and **Architecture Stakeholders. System Stakeholders** are subject of system modeling and formulate needs that should be satisfied by the system of interest.
 **Architecture Stakeholders** formulate information needs (**concerns**), that must be answered by the Frameworks **Viewpoints**
 
-See the [SAF Stakeholder documentation](./userdoc/stakeholders.md).
+See the [SAF Stakeholder documentation](stakeholders.md).
 
 *The Stakeholder concept is layed out in ISO 42010*
 
@@ -36,15 +36,15 @@ For example, the user has specific concerns which interactions he or she has wit
 
 The stakeholders concerns are specific to the lifecycle project phase, e.g., at a PDR, subsystem responsibles have the information need which systems function are delegated to their subsystems, while at a CDR they would need to know about the interface designs of other neighbor subsystems.
 
-See the [SAF concern documentation](userdoc/concerns.html).
+See the [SAF concern documentation](concerns.html).
 
 *The Concern concept is layed out in ISO 42010*
 
 ## Domains
 **What are Domains?**
 The rows of the SAF grid are called  domains. They organize the viewpoints in a way that typical engineering workflows follow the viewpoints in one domain, then continue to the next domain. 
 
-See the [SAF domain Documentation](./userdoc/domains.md)
+See the [SAF domain Documentation](domains.md)
 
 *The Domain concept implements the Stakeholder Perspective layed out in ISO 42010*
 
@@ -53,7 +53,7 @@ See the [SAF domain Documentation](./userdoc/domains.md)
 
 The columns of the SAF grid are called aspects. They organize the viewpoints by the kind of information need of stakeholders, typically similar diagram kinds appear together in the same aspect, and typically the same information need appears in multiple domains. 
 
-See the [SAF aspect Documentation](./userdoc/aspects.md)
+See the [SAF aspect Documentation](aspects.md)
 
 *The Aspect concept is layed out in ISO 42010*
 

src/userdoc/stakeholders.md

@@ -6,7 +6,7 @@ nav_order: 2
 ---
 # Stakeholders
 ![SAF_Stakeholder_Definition](../assets/images/SAF_stakeholder_definition.svg)
-This section provides a list of the Stakeholder roles considered for the elicitation of concerns for SAF viewpoints. For each of the Stakeholders their [concerns](../faq.md#concerns) are listed.
+This section provides a list of the Stakeholder roles considered for the elicitation of concerns for SAF viewpoints. For each of the Stakeholders their [concerns](faq.md#concerns) are listed.
 
 The following subchapters describe the stakeholders and their concerns:
 

src/structure.md → src/userdoc/structure.md

@@ -21,20 +21,20 @@ Because of this, SAF helps to execute an MBSE effort by a plan which is backed b
 The viewpoints specify, which model elements shall be created in which kind of diagrams to serve the viewpoints purpose and adress the concerns of the stakeholders interested in the viewpoints. 
 
 ### SAF Viewpoint Grid
-The SAF Viewpoints are organized as a Grid featuring [Domains](./userdoc/domains.md) as rows and [Aspects](./userdoc/aspects.md) as columns.
+The SAF Viewpoints are organized as a Grid featuring [Domains](domains.md) as rows and [Aspects](aspects.md) as columns.
 
 ### Domains follow engineering workflow
-The [Domains](./userdoc/domains.md)  are oriented by a typical engineering workflow. 
- * The [Common Domain](./userdoc/common.md) contains workflow overarcing content such as Terms and Standards. 
- * The [Operational Domain](./userdoc/operational.md) adresses information need during the concept phase (Mission Analysis and Stakeholder Requirements elicitation)
- * The [Functional Domain](./userdoc/functional.md) adresses information needs during the System Requirements Definition Process (The System blackbox on a conceptual level)
- * The [Logical Domain](./userdoc/logical.md) adresses information needs during the Architecture Definition Process (the System Whitebox on conceptual level)
- * The [Physical Domain](./userdoc/physical.md) adresses information needs during the Design Definition Process (the System Black Box and Whitebox on solution / design level)
+The [Domains](domains.md)  are oriented by a typical engineering workflow. 
+ * The [Common Domain](common.md) contains workflow overarcing content such as Terms and Standards. 
+ * The [Operational Domain](operational.md) adresses information need during the concept phase (Mission Analysis and Stakeholder Requirements elicitation)
+ * The [Functional Domain](functional.md) adresses information needs during the System Requirements Definition Process (The System blackbox on a conceptual level)
+ * The [Logical Domain](logical.md) adresses information needs during the Architecture Definition Process (the System Whitebox on conceptual level)
+ * The [Physical Domain](physical.md) adresses information needs during the Design Definition Process (the System Black Box and Whitebox on solution / design level)
 
 ### Aspects follow kinds of concerns
-The  [Aspects](./userdoc/aspects.md) are oriented by the kind of information needs, e.g. questions about structure are answered by viewpoints in the taxonomy and structure aspect. Typically similar kinds of questions need to be answered in multiple domains, hence the organisation of grid columns.
+The  [Aspects](aspects.md) are oriented by the kind of information needs, e.g. questions about structure are answered by viewpoints in the taxonomy and structure aspect. Typically similar kinds of questions need to be answered in multiple domains, hence the organisation of grid columns.
 
-![SAF Grid](./assets/images/SAF_Viewpoint-Grid-Structuring-Formalism.svg)
+![SAF Grid](../assets/images/SAF_Viewpoint-Grid-Structuring-Formalism.svg)
 
 
 ## Recursive Application of the Framework due to System decomposition