index.xhtml 15 KB
Newer Older
1 2 3
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "">
<html version="-//W3C//DTD XHTML 1.1//EN" xsi:schemaLocation="" xml:lang="en" lang="en" xmlns:xsi="" xmlns:sos="" xmlns=""><head><meta http-equiv="content-type" content="application/xhtml+xml; charset=UTF-8"/>
<!-- This file was created by sos_xml_to_sos_grid_xhtml_1.xsl of SOS Grid Prototype 2, which is free software licensed under the GNU Affero General Public License 3 or any later version (see and -->
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Copyright (C) 2018-2019 Stephan Kreutzer

This file is part of SOS Grid Prototype 2.

SOS Grid Prototype 2 is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License version 3 or any later version,
as published by the Free Software Foundation.

SOS Grid Prototype 2 is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
GNU Affero General Public License 3 for more details.

You should have received a copy of the GNU Affero General Public License 3
along with SOS Grid Prototype 2. If not, see <>.

The data in the <div id="sos-input"/> is not part of this program,
it's user data that is only processed. A different license may apply.
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
<title>SOS Grid Prototype 2</title><meta content="initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no" name="viewport"/><link rel="stylesheet" type="text/css" href="./css/styles.css"/><script type="text/javascript" src="./js/sos-grid-engine.js">//</script><script type="text/javascript" src="./js/sos-grid-renderer.js">//</script><script type="text/javascript" src="./js/sos-grid-navigation.js">//</script><script type="text/javascript">
"use strict";

// As browsers/W3C/WHATWG are incredibly evil, they might ignore the self-declarative
// XML namespace of this document and the given content type in the header, and instead
// assume/render "text/html", which then fails with JavaScript characters that are
// XML/XHTML special characters which need to be escaped, if the file is saved under
// a name that happens to end with ".html" (!!!). Just have the file name end with
// ".xhtml" and it might magically start to work.

function loadGrid()
    if (window.location.hash.length &gt; 1)
        // NavigateIssue() with empty ID string: load the "default" (first) Issue.

window.onload = function () {
    let loadLink = document.getElementById('loadLink');


    if ("onhashchange" in window)
        window.onhashchange = loadGrid;
</script></head><body><div id="grid"><div id="causes"/><div id="current"/><div id="effects"/><div id="details"/><div id="loadLink"><a href="#" onclick="loadGrid();">Load</a></div></div><div id="sos-input" style="display:none;"><!-- The data contained in this element and sub-elements is not part of this program, it's user data and might be under a different license than this program. This program also doesn't depend on it or link it as a library, it's only processed. --><sos:SOS Language="en" xsi:schemaLocation="">
  <sos:Issue id="1">
    <sos:Title>The browser is sandboxed</sos:Title>
    <sos:Text>Our prototypes are implemented in the browser. The issue is the “Same Origin Policy” and the problem that Cross-Origin Resource Sharing requires the cooperation of remote, external entities in advance.</sos:Text>
    <sos:Cause id="2">
      <sos:Title>Remote code execution</sos:Title>
      <sos:Text>The browser executes unchecked code retrieved from remote, external entities. Such code can be malicious. The browser needs to sandbox the execution in order to protect the computer from compromization. Reasons for it are that no software installation is required in advance (dynamic loading and execution on demand), and that the operating systems running the majority of browsers lack the concept of software distribution repositories where code is submitted and checked, as most of the remote code is proprietary, as well as the operating system that supports this model of denying digital freedom to the user, so the code must be obtained from the original author and can’t be fixed (if broken or malicious), to establish and maintain the dependency.</sos:Text>
    <sos:Cause id="3">
      <sos:Title>Leakage of confidential data</sos:Title>
      <sos:Text>If the browser gets and executes unchecked code from various remote, external entities, it could send the confidential data hold by the other code back from where itself came from and leak it.</sos:Text>
    <sos:Cause id="4">
      <sos:Title>Business model of online service dependency</sos:Title>
      <sos:Text>Browser vendors tend to be engaged in some form of SaaS online service lock-in dependency business model, so it would harm their business interest if the sandbox wouldn’t enforce the use of these services and instead would allow to make use of local alternatives.</sos:Text>
    <sos:Effect id="5">
      <sos:Title>Limitations for offline use</sos:Title>
      <sos:Text>Data can’t be loaded from or stored to the local hard drive. It’s impossible to interoperate with existing other software on the system. It’s impossible to retrieve data from or submit data to a remote server.</sos:Text>
    <sos:Effect id="6">
      <sos:Title>Quasi-reqirement of online use</sos:Title>
      <sos:Text>No data exchange can happen conveniently if it isn’t done with the original remote, external server that delivered the web application files. The operator of the server that delivered the web application files will be faced with responsibilities like data protection, preventing data loss, security, quality of service (uptime and providing the service, so if the service is discontinued, people will loose their work), demands of law enforcement, etc. If the user doesn’t have connectivity, some functions won’t work, for example: uploading a file in order to share/publish and then retrieve it again from the original remote server, because local files can’t be added to the local web software.</sos:Text>
  <sos:Issue id="7">
    <sos:Title>No neutral repository</sos:Title>
    <sos:Text>The repository for the prototypes and examples is a personal repository that’s attached to skreutzer’s account:</sos:Text>
    <sos:Cause id="8">
      <sos:Text>No prior organizational structures, ad-hoc setup.</sos:Text>
    <sos:Effect id="9">
      <sos:Title>Bad for linking</sos:Title>
      <sos:Text>Links to the repository will lead to skreutzer’s account. A redirect likely can’t be set up later, so moving the repository later likely will break existing links.</sos:Text>
    <sos:Effect id="10">
      <sos:Title>Bad context</sos:Title>
      <sos:Text>It’s only a single personal repository on skreutzer’s account, where the context and environment holds many other repositories as well that aren’t related to SOS, so somebody who explores the repository wouldn’t find other SOS material, but unrelated projects, which is bad for the discoverability of the SOS projects. Other SOS repositories aren’t collected in one place, but spread and mixed with other stuff, which is confusing. There is no one-stop-shop authoritative place where all the materials can be found.</sos:Text>
    <sos:Effect id="32">
      <sos:Title>Bad for community management</sos:Title>
      <sos:Text>It’s difficult and risky for other people to join and participate, if their contributions are bound to a personal account that’s not related to SOS. Connections might get lost for SOS if a transition needs to happen later.</sos:Text>
    <sos:Effect id="33">
      <sos:Title>Bus factor</sos:Title>
      <sos:Text>With git, forking is easy and cheap, so it’s not an effect of too much importance yet that the experimental repository for examples and prototypes is operated by a single person and in case of mishap, malicious actions or loss of availability/interest might become inacessible.</sos:Text>
    <sos:Effect id="11">
      <sos:Title>No connections from SOS</sos:Title>
      <sos:Text>There’s no connection from the wcharlton user account nor from the official website to the repository, which is bad for discoverability and relies solely on wcharlton’s responsibility to indicate the existence of it, in terms of bus factor.</sos:Text>
  <sos:Issue id="12">
    <sos:Title>Unpublished material</sos:Title>
    <sos:Text>Some of William Charlton’s material isn’t published like the grid interface mockup drawings, HTML grid interface mockup, ASPX server prototype, the “SOS - Meeting for Untied Nations/The Ecology of Systems Thinking” and “SOS - Meeting for Cape Town Hackathon” files with their corresponding XSLTs.</sos:Text>
    <sos:Cause id="13">
      <sos:Text>No prior organizational structures, ad-hoc setup.</sos:Text>
    <sos:Cause id="14">
      <sos:Title>No repository</sos:Title>
      <sos:Text>In lack of a shared repository or a personal repository, there is no good place to publish them.</sos:Text>
    <sos:Cause id="15">
      <sos:Text>For the publication of the material to make sense and be useful, it should be licensed properly. This requires William Charlton to consider the licenses and deciding on one or several of them.</sos:Text>
    <sos:Effect id="16">
      <sos:Title>Incompleteness, not open</sos:Title>
      <sos:Text>People who look into the project via the site or the sos-experimental repository won’t be able to get an overview of what has been produced so far. Potential collaborators or independent contributors won’t have access to all the files and might start to waste time by producing similar material which was already produced, but isn’t available.</sos:Text>
    <sos:Effect id="17">
      <sos:Title>No versioning</sos:Title>
      <sos:Text>It’s difficult to keep track of the different versions of a file and it can’t easily be established from a given file if it is current or an historic version.</sos:Text>
    <sos:Effect id="18">
      <sos:Title>Backup is difficult</sos:Title>
      <sos:Text>It takes a lot of effort to spread the individual files in order to have copies of the whole collection everywhere as a backup mechanism if the original repository or (e-mail) accounts become unavailable.</sos:Text>
  <sos:Issue id="19">
    <sos:Title>SOS formats differ</sos:Title>
    <sos:Text>Stephan Kreutzer’s example files differ from William Charlton’s example files. Stephan Kreutzer’s prototypes expect a different format than William Charlton’s prototypes expect. Stephan Kreutzer’s example files don’t validate according to the official XSD.</sos:Text>
    <sos:Cause id="20">
      <sos:Text>No prior discussion, fast prototyping. Saving the time that would be required for co-designing. Experimentation to potentially adjust/improve the final format.</sos:Text>
    <sos:Effect id="21">
      <sos:Title>Not interoperable</sos:Title>
      <sos:Text>Because of differing formats, the prototypes are incompatible and example files are specific to only one of the two prototype groups. The examples can’t be demonstrated to work with all of the prototypes.</sos:Text>
  <sos:Issue id="22">
    <sos:Title>What about Meetings?</sos:Title>
    <sos:Text>It’s unclear what role Meetings should play. They’re in the format, but examples were produced without a meeting (or how is “Meeting” defined?) and the prototypes can be used without as well.</sos:Text>
    <sos:Cause id="23">
      <sos:Title>SOS is also a human system tool</sos:Title>
      <sos:Text>SOS planning is a method/process/procedure, not just a software tool. It’s intended to be used in specific contexts and setups. The prototypes don’t reflect that yet.</sos:Text>
    <sos:Cause id="24">
      <sos:Title>Is pre-existing</sos:Title>
      <sos:Text>The Meeting is in William Charlton’s example files and prototypes that pre-existed the creation of this Issue.</sos:Text>
    <sos:Effect id="25">
      <sos:Title>Meetings not reflected in all examples and prototypes</sos:Title>
      <sos:Text>Stephan Kreutzer’s examples and prototypes don’t reflect the concept of the Meeting, which leads to incompatibility with William Charlton’s examples and prototypes that do implement the concept of the Meeting.</sos:Text>
  <sos:Issue id="26">
    <sos:Title>Progress isn’t visible</sos:Title>
    <sos:Text>Visitors and potential collaborators/contributors can’t find out about the progress of the project.</sos:Text>
    <sos:Cause id="27">
      <sos:Text>No prior organizational structures, ad-hoc setup.</sos:Text>
    <sos:Effect id="28">
      <sos:Title>Not very engaging</sos:Title>
      <sos:Text>Visitors, potential collaborators and potential contributors might not get attracted because of thinking that the project is inactive.</sos:Text>
  <sos:Issue id="29">
    <sos:Title>No production system</sos:Title>
    <sos:Text>The examples and prototypes are somewhat fixed/frozen, they serve as mere examples that shouldn’t be polluted with expansion as a result of real-world usage in order to remain useful and concise, with focus on specific features and characteristics. For the real bootstrapping of this project effort, there’s no production system/environment that also allows organizational enhancements like notifications or versioning to track the history.</sos:Text>
    <sos:Cause id="30">
      <sos:Text>No prior organizational structures, ad-hoc setup.</sos:Text>
    <sos:Effect id="31">
      <sos:Title>Progress is limited</sos:Title>
      <sos:Text>Bootstrapping can’t improve and advance to a higher stage as the existing results aren’t supposed to and don’t contribute to the actual project effort itself.</sos:Text>