Merge pull request #1960 from w3c/ege-formatting-2

Auto formatting

.editorconfig

@@ -0,0 +1,21 @@
+# This file allows you to configure your editor using [EditorConfig](https://EditorConfig.org).
+# Make sure to install the EditorConfig plugin if your editor doesn't come with built-in support.
+
+# top-most EditorConfig file
+root = true
+
+[*]
+indent_style = space # useTabs=false in prettier
+indent_size = 2 # tabWidth in prettier
+end_of_line = lf # endOfLine in prettier
+charset = utf-8 # not configurable in prettier
+trim_trailing_whitespace = false # not configurable in prettier
+insert_final_newline = true # always true in prettier
+
+[{/publication/**,/node_modules/**,index.html,validation/tm-json-schema-validation.json,context/td-context-1.1.jsonld,visualization/*.png,visualization/*.svg}]
+indent_style = unset
+indent_size = unset
+end_of_line = unset
+charset = unset
+trim_trailing_whitespace = unset
+insert_final_newline = unset

.gitattributes

@@ -0,0 +1,39 @@
+# Set default behaviour, in case users don't have core.autocrlf set.
+* text=auto
+
+# Explicitly declare text files we want to always be normalized and converted
+# to native line endings on checkout.
+
+# Declare files that will always have LF line endings on checkout.
+*.c text eol=lf
+*.css text eol=lf
+*.cpp text eol=lf
+.editorconfig text eol=lf
+.gitattributes text eol=lf
+.gitignore text eol=lf
+.gitmodules text eol=lf
+*.gyp text eol=lf
+*.h text eol=lf
+*.hpp text eol=lf
+*.html text eol=lf
+*.js text eol=lf
+*.ts text eol=lf
+*.json text eol=lf
+LICENSE text eol=lf
+*.md text eol=lf
+*.puml text eol=lf
+*.svg text eol=lf
+*.sh text eol=lf
+*.sparql text eol=lf
+*.ttl text eol=lf
+*.yml text eol=lf
+
+# Declare files that will always have CRLF line endings on checkout.
+*.bat text eol=crlf
+*.cmd text eol=crlf
+
+# Denote all files that are truly binary and should not be modified.
+*.gif binary
+*.jpg binary
+*.node binary
+*.png binary

.github/workflows/assertion-sync.yml

@@ -5,7 +5,7 @@ name: Synchronize Assertions
 # Controls when the workflow will run
 on:
   schedule:
-    - cron:  '00 00 * * *'
+    - cron: "00 00 * * *"
 
   # Allows you to run this workflow manually from the Actions tab
   workflow_dispatch:
@@ -20,20 +20,20 @@ jobs:
       - uses: actions/checkout@v2
       - uses: actions/setup-node@v2
         with:
-          node-version: '16'
+          node-version: "16"
       - name: Install Dependencies
         run: npm install
       - name: Copy Template.csv
-      # This is done so that it can be compared later on
+        # This is done so that it can be compared later on
         run: |
           mkdir .temp
           cp testing/assertions.csv .temp/assertions.current.csv
           cat .temp/assertions.current.csv
       - name: generate template.csv
-      # this generates other stuff as well but we are interested in template.csv
+        # this generates other stuff as well but we are interested in template.csv
         run: node testing/extractFile.js > testing/assertions.csv
       - name: Look for changes
-        continue-on-error: true 
+        continue-on-error: true
         run: |
           cat testing/assertions.csv
           git diff --no-index testing/assertions.csv .temp/assertions.current.csv
@@ -60,11 +60,10 @@ jobs:
             testing/assertions.csv
           branch: assertion-csv-sync
           delete-branch: true
-          title: 'Update assertions.csv for testing'
+          title: "Update assertions.csv for testing"
           body: |
             Update template.csv
             - Updated with *today's* date
             - Auto-generated by [create-pull-request][1]
 
             [1]: https://github.com/peter-evans/create-pull-request
-

.github/workflows/validation.yml

@@ -1,9 +1,9 @@
 name: Validation tests
 
-on: 
+on:
   pull_request:
-    branches:    
-        - main
+    branches:
+      - main
 
 jobs:
   test:

.husky/pre-commit

@@ -10,8 +10,9 @@ echo "Working directory clear"
 
 npm run render
 npm run generateTmSchema
+npm run format
 
-echo "Rendering complete"
+echo "Rendering, TM schema generation, formatting complete"
 
 git add -u # adding generated files 
 

.pr-preview.json

@@ -1,4 +1,4 @@
 {
-    "src_file": "index.html",
-    "type": "respec"
-    }
+  "src_file": "index.html",
+  "type": "respec"
+}

.prettierignore

@@ -0,0 +1,18 @@
+# Files added by default, repeating for transparency
+**/.git
+**/.svn
+**/.hg
+**/node_modules
+
+# Publication-related files
+publication
+errata.html
+errata11.html
+
+# Automatically generated files
+ontology/*.html
+index.html
+validation/tm-json-schema-validation.json
+context/td-context-1.1.jsonld
+visualization/*.png
+visualization/*.svg

.prettierrc.json

@@ -0,0 +1,8 @@
+{
+  "tabWidth": 2,
+  "useTabs": false,
+  "endOfLine": "lf",
+  "printWidth": 120,
+  "quoteProps": "preserve",
+  "trailingComma": "none"
+}

README.md

@@ -4,43 +4,46 @@
 [![Stack Exchange questions](https://img.shields.io/stackexchange/stackoverflow/t/web-of-things?style=plastic)](https://stackoverflow.com/questions/tagged/web-of-things)
 
 General information about the Web of Things can be found on https://www.w3.org/WoT/.
-  
+
 ---
 
 Each commit here will sync to the master, which will expose the content to http://w3c.github.io/wot-thing-description/.
 
 For the draft TD specification for TAG review, please access this [URL](https://cdn.staticaly.com/gh/w3c/wot-thing-description/TD-TAG-review/index.html?env=dev).
 
 To make contributions, please provide pull requests to the appropriate files,
-keeping in mind that some files, most notably `index.html` and `testing/report.html`, 
+keeping in mind that some files, most notably `index.html` and `testing/report.html`,
 as well as most files under `visualization`, are
 autogenerated and should not be modified directly.
-See [github help](https://help.github.com/articles/using-pull-requests/) for 
+See [github help](https://help.github.com/articles/using-pull-requests/) for
 information on how to create a pull request.
 
-__Note (July 2023):__
+**Note (July 2023):**
 
-__Please notice that Thing Description 1.1 is in the review phase for the Recommendation transition. 
-In this phase, only editorial changes (e.g., adding examples, additional explanations) and bug fixes can be applied to the [editorial draft](http://w3c.github.io/wot-thing-description/) if the whole Working Group agrees on it. Editorial changes should be labeled with 'Editorial' in the issue and corresponding PRs. New feature requests can not be considered and will be postponed to the next version of the Thing Description.__  
+**Please notice that Thing Description 1.1 is in the review phase for the Recommendation transition.
+In this phase, only editorial changes (e.g., adding examples, additional explanations) and bug fixes can be applied to the [editorial draft](http://w3c.github.io/wot-thing-description/) if the whole Working Group agrees on it. Editorial changes should be labeled with 'Editorial' in the issue and corresponding PRs. New feature requests can not be considered and will be postponed to the next version of the Thing Description.**
 
 ## Thing Description Family
+
 This repository covers the W3C Web of Things Thing Description family of specifications.
 
 ### Thing Description 1.1 (Maintenance)
-* [Editor's Draft](http://w3c.github.io/wot-thing-description/) - Latest editor's draft of the Thing Description Maintenance version 
-* [Working Draft](https://www.w3.org/TR/wot-thing-description11/) - Latest working draft of the Thing Description Maintenance version 
-* [branch](https://github.com/w3c/wot-thing-description/tree/main) - Points to the main branch of this repository
+
+- [Editor's Draft](http://w3c.github.io/wot-thing-description/) - Latest editor's draft of the Thing Description Maintenance version
+- [Working Draft](https://www.w3.org/TR/wot-thing-description11/) - Latest working draft of the Thing Description Maintenance version
+- [branch](https://github.com/w3c/wot-thing-description/tree/main) - Points to the main branch of this repository
 
 ### Thing Description 1.0
-* [REC](https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/) - Official recommendation version of the Thing Description 1.0
-* [branch](https://github.com/w3c/wot-thing-description/tree/wot-td-1.0) - Branch that corresponds to the Thing Description 1.0 files
-* [errata](https://w3c.github.io/wot-thing-description/errata.html) -  Errata for version 1.0 
+
+- [REC](https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/) - Official recommendation version of the Thing Description 1.0
+- [branch](https://github.com/w3c/wot-thing-description/tree/wot-td-1.0) - Branch that corresponds to the Thing Description 1.0 files
+- [errata](https://w3c.github.io/wot-thing-description/errata.html) - Errata for version 1.0
 
 ## Specification Rendering
 
 Part of the document is automatically rendered using the [STTL.js](https://github.com/vcharpenay/STTL.js/) RDF template engine and Node.js.
 _Any change to the document must be performed on the main HTML template [`index.template.html`](index.template.html)_, and not on `index.html`.
-To render `index.html`, along with SVG figures, run: 
+To render `index.html`, along with SVG figures, run:
 
 - `npm install` to install all the dependencies
 - `npm run render` to render all the files
@@ -61,7 +64,7 @@ For Windows users, the script should be run in a [Cygwin shell](http://cygwin.co
 ### Automatic rendering
 
 The repository is equipped with git hooks that automate the rendering process. To enable them, run `npm install` in the root folder. The hooks will render the documents automatically at every commit.
-If you run the rending process manually or you do not want to execute the automatic process add the `--no-verify` option to your commit command. 
+If you run the rending process manually or you do not want to execute the automatic process add the `--no-verify` option to your commit command.
 
 ## Implementation Report
 
@@ -72,36 +75,37 @@ issue the following command:
 ```sh
 npm run assertions
 ```
+
 A draft implementation report will be generated and output to
 [testing/report.html](testing/report.html)
 which will use relative links back up to [index.html](index.html).
 The input to this process is [index.html](index.html)
 (_not_ `index.html.template`) so make sure to execute `npm run render` first.
 
-For this to work, the assertions need to 
+For this to work, the assertions need to
 be marked up as in the following examples and follow RFC2119 conventions:
+
 ```html
 <span class="rfc2119-assertion" id="additional-vocabularies">
-  A JSON TD MAY contain additional optional vocabularies that are 
-  not in the Thing Description core model.
+  A JSON TD MAY contain additional optional vocabularies that are not in the Thing Description core model.
 </span>
 <span class="rfc2119-assertion" id="additional-vocabularies-prefix">
-  Terms from additional optional vocabularies used in a JSON-TD MUST 
-  carry a prefix for identification within the key name
-  (e.g., <tt>"http:header"</tt>).
+  Terms from additional optional vocabularies used in a JSON-TD MUST carry a prefix for identification within the key
+  name (e.g., <tt>"http:header"</tt>).
 </span>
 ```
 
 The assertions must be marked up as follows:
-* Enclose each assertion in a span.
-* Mark the span with a unique id.
+
+- Enclose each assertion in a span.
+- Mark the span with a unique id.
   It is recommended that the section id be followed
   by a short unique name for the specific assertion.
-* Mark the span with a 'class' attribute set to `rfc2119-assertion`.
-* Include one (and only one) instance of the RFC2119 keywords (MUST, MAY, etc.)
+- Mark the span with a 'class' attribute set to `rfc2119-assertion`.
+- Include one (and only one) instance of the RFC2119 keywords (MUST, MAY, etc.)
   in capitals.
-This markup does not change the rendering; it just clearly indicates
-and uniquely names the assertion.
+  This markup does not change the rendering; it just clearly indicates
+  and uniquely names the assertion.
 
 It is strongly recommended to make assertions independent of context.
 In particular, avoid using pronouns or relational expressions
@@ -116,18 +120,18 @@ Also, assertions should ideally only constrain one item.
 Multiple constraints should be stated in separate sentences.
 
 Note that the above rendering process also assigns each
-table entry a unique ID and these are also listed in the 
+table entry a unique ID and these are also listed in the
 table included in the implementation report.
 
 Other data, e.g., data from test results, test specifications,
-and implementation descriptions, are also needed to complete the 
-implementation report.  See [testing/README.md](testing/README.md)
+and implementation descriptions, are also needed to complete the
+implementation report. See [testing/README.md](testing/README.md)
 for details.
 
 The generation of the implementation report also generates a CSS file
 `testing/atrisk.css`
-that highlights at-risk items in the generated `index.html`.  The at-risk
-items are listed in `testing/inputs/atrisk.csv`.  If at-risk items are
+that highlights at-risk items in the generated `index.html`. The at-risk
+items are listed in `testing/inputs/atrisk.csv`. If at-risk items are
 updated, to update the at-risk highlighting the implementation report
 needs to be generated first, and then the rendering.
 
@@ -141,15 +145,15 @@ These are categorized below and their use cases explained.
 The present specification introduces the TD Information Model as a set of constraints over different vocabularies.
 The current list of vocabularies are found under [the namespaces section](https://w3c.github.io/wot-thing-description/#namespaces).
 
-By default, if a user agent does not perform any content negotiation, a human-readable HTML documentation is returned instead of the RDF document. 
+By default, if a user agent does not perform any content negotiation, a human-readable HTML documentation is returned instead of the RDF document.
 To negotiate content, clients must include the HTTP header `Accept: text/turtle` in their request.
 
 The working documents are found under the [ontology](./ontology) folder.
 
 ### Context files
 
 In order to have reference to the TD ontology within JSON-LD documents, including TDs, we provide a JSON-LD context file.
-The working document can be found at [context/td-context-1.1.jsonld](./context/td-context-1.1.jsonld) and the version-specific context file can be retrieved from the `@context` value of a TD 1.0 or TD 1.1 instance. **Note** that  [context/td-context-1.1.jsonld](./context/td-context-1.1.jsonld) is the result of the rendering process and it should not be edited manually. In practice, the rendering process merges [context/td-context.jsonld](./context/td-context.jsonld), [context/json-schema-context.jsonld](./context/json-schema-context.jsonld), [context/wot-security-context.jsonld](./context/wot-security-context.jsonld), [context/hypermedia-context.jsonld](./context/hypermedia-context.jsonld).  
+The working document can be found at [context/td-context-1.1.jsonld](./context/td-context-1.1.jsonld) and the version-specific context file can be retrieved from the `@context` value of a TD 1.0 or TD 1.1 instance. **Note** that [context/td-context-1.1.jsonld](./context/td-context-1.1.jsonld) is the result of the rendering process and it should not be edited manually. In practice, the rendering process merges [context/td-context.jsonld](./context/td-context.jsonld), [context/json-schema-context.jsonld](./context/json-schema-context.jsonld), [context/wot-security-context.jsonld](./context/wot-security-context.jsonld), [context/hypermedia-context.jsonld](./context/hypermedia-context.jsonld).
 
 You can find more information on how to use the context at [the Appendix of the TD specification](https://w3c.github.io/wot-thing-description/#json-ld-ctx-usage).
 
@@ -159,12 +163,12 @@ We provide JSON Schema for TD and TM instances.
 The working documents are found under the [validation](./validation/) folder and specific versions are linked from the Thing Description specification.
 These can be used for the purposes below among others:
 
-* TD and TM validation
-* Type generation for programming languages
+- TD and TM validation
+- Type generation for programming languages
 
 ## Obsolete Documents
 
 Some documents of this repository are not required to be kept in the upstream branch (main branch).
 They are deleted but are recorded below with a link pointing to a tagged branch:
 
-* Review of the main document for TAG: <https://github.com/w3c/wot-thing-description/blob/CR-request/tag-review.html>
+- Review of the main document for TAG: <https://github.com/w3c/wot-thing-description/blob/CR-request/tag-review.html>

VERSIONING.md

@@ -40,6 +40,6 @@ Text copied from <https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebCon
     - TTL
     - HTML
 - How much time to invest in maintaining 1.1 resources?
-– Maintaining multiple files or not: xxx.v1.1.0.ttl xxx.v1.1.1.ttl
+  – Maintaining multiple files or not: xxx.v1.1.0.ttl xxx.v1.1.1.ttl
 - Decision so far: Do not dig into 1.1 versioning until we have the need.
 - TM resources (tm.ttl and tm.html) will not be versioned for the first changes since HTML doesn't exist and TTL is not usable.