diff --git a/report.json b/report.json index c4dadbb..1b92603 100644 --- a/report.json +++ b/report.json @@ -89,6 +89,7 @@ "w3c/wot-thing-description-toolchain-tmp", "w3c/wot-tools", "w3c/xmldsig", + "w3ctag/.github", "w3ctag/accessibility-questionnaire", "w3ctag/accessibility-responses", "w3ctag/bfcache-guide", @@ -123,6 +124,7 @@ "w3ctag/unsanctioned-tracking", "w3ctag/url", "w3ctag/urls-in-data", + "w3ctag/user-agents", "w3ctag/w3ctagbot", "w3ctag/web-https", "w3ctag/web-without-3p-cookies", @@ -3848,6 +3850,7 @@ "w3cping/administrivia", "w3cping/privacy-request", "w3cping/tracking-issues", + "w3ctag/.github", "w3ctag/accessibility-questionnaire", "w3ctag/accessibility-responses", "w3ctag/bfcache-guide", @@ -3885,6 +3888,7 @@ "w3ctag/unsanctioned-tracking", "w3ctag/url", "w3ctag/urls-in-data", + "w3ctag/user-agents", "w3ctag/w3ctagbot", "w3ctag/web-https", "w3ctag/web-without-3p-cookies", @@ -9862,7 +9866,7 @@ } ] }, - "timestamp": "2024-12-16T00:23:28.268Z", + "timestamp": "2024-12-17T00:24:29.920Z", "repos": [ { "id": "MDEwOlJlcG9zaXRvcnk4MTAyMTg2MA==", @@ -27885,7 +27889,7 @@ }, "prpreviewjson": null, "autoPublish": { - "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Workflow runs on pull requests where it makes sure that the spec can still\n # be generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-20.04\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v2\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" + "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Workflow runs on pull requests where it makes sure that the spec can still\n # be generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-latest\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v4\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" }, "travis": null, "contributing": { @@ -42079,6 +42083,14 @@ "name": "scope", "color": "C2E0C6" }, + { + "name": "sector", + "color": "D5B5C0" + }, + { + "name": "standards", + "color": "BAC760" + }, { "name": "tech", "color": "d4c5f9" @@ -74962,7 +74974,7 @@ "text": "{\n \"src_file\": \"index.bs\",\n \"type\": \"bikeshed\",\n \"params\": {\n \"force\": 1\n }\n}\n" }, "autoPublish": { - "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Worflow runs on pull requests where it makes sure that the spec can still be\n # generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-20.04\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v2\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" + "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Worflow runs on pull requests where it makes sure that the spec can still be\n # generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-latest\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v4\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" }, "travis": null, "contributing": { @@ -85465,7 +85477,7 @@ "text": "{\n \"src_file\": \"index.bs\",\n \"type\": \"bikeshed\",\n \"params\": {\n \"force\": 1\n }\n}\n" }, "autoPublish": { - "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Worflow runs on pull requests where it makes sure that the spec can still be\n # generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-20.04\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v2\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" + "text": "# Workflow based on the main w3c/spec-prod action example:\n# https://github.com/w3c/spec-prod/#basic-usage\n\nname: Build, Validate, Deploy and Publish\n\non:\n # Worflow runs on pull requests where it makes sure that the spec can still be\n # generated, that markup is valid and that there are no broken links, as\n # well as on pushes to the default branch where it also deploys the generated\n # spec to the gh-pages branch and publishes the result to /TR.\n # The \"workflow_dispatch\" hook allows admins to also trigger the workflow\n # manually from GitHub's UI.\n pull_request: {}\n push:\n branches: [main]\n workflow_dispatch:\n\njobs:\n main:\n runs-on: ubuntu-latest\n steps:\n # See doc at https://github.com/actions/checkout#checkout-v2\n - name: Checkout repository\n uses: actions/checkout@v4\n\n # See doc at https://github.com/w3c/spec-prod/#spec-prod\n # The action only deploys the generated spec to the gh-pages branch when\n # the workflow was triggered by a push to the default branch.\n - name: Build and validate index.html, push to gh-pages branch if needed\n uses: w3c/spec-prod@v2\n with:\n GH_PAGES_BRANCH: gh-pages\n W3C_ECHIDNA_TOKEN: ${{ secrets.ECHIDNA_TOKEN }}\n W3C_WG_DECISION_URL: https://github.com/w3c/media-wg/issues/27\n W3C_BUILD_OVERRIDE: |\n status: WD\n" }, "travis": null, "contributing": { @@ -110088,7 +110100,7 @@ "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n" }, "readme": { - "text": "# timezone - Working with Time and Timezones\n\n### Documents\n- [Editor's copy](https://w3c.github.io/timezone/)\n- [WD](https://www.w3.org/TR/timezone/)\n\n### Feedback\nPlease use the [GitHub issue list](https://github.com/w3c/timezone/issues) to send feedback about this document.\n\nTo make it easier to track comments, please raise separate issues for each comment, and point to the section you are commenting on using a URL for the dated version of the document.\n\n### Following\nTo follow the work, you can 'Watch' this repository using the control above, or subscribe to the [www-international](https://lists.w3.org/Archives/Public/www-international/) mailing list, which is notified once a day about changes to the repo. Please use github issues rather than the mailing list to send feedback.\n\n### Contributing\n\nAll contributors should read and agree with [CONTRIBUTING.md](https://github.com/w3c/bp-i18n-specdev/blob/gh-pages/CONTRIBUTING.md).\n\nEditors should be familiar with and use the following:\n\n- [Github guidelines for working with i18n documents](http://w3c.github.io/i18n-activity/guidelines/github)\n- [Editorial guidelines for working with i18n documents](http://w3c.github.io/i18n-activity/guidelines/editing)\n\n### Links\n- [Working Group Home Page](http://w3c.github.io/i18n-activity/i18n-wg/)\n" + "text": "# timezone - Working with Time and Timezones\n\n### Documents\n- [Editor's copy](https://w3c.github.io/timezone/)\n- [DNOTE](https://www.w3.org/TR/timezone/)\n\n### Feedback\nPlease use the [GitHub issue list](https://github.com/w3c/timezone/issues) to send feedback about this document.\n\nTo make it easier to track comments, please raise separate issues for each comment, and point to the section you are commenting on using a URL for the dated version of the document.\n\n### Following\nTo follow the work, you can 'Watch' this repository using the control above, or subscribe to the [www-international](https://lists.w3.org/Archives/Public/www-international/) mailing list, which is notified once a day about changes to the repo. Please use github issues rather than the mailing list to send feedback.\n\n### Contributing\n\nAll contributors should read and agree with [CONTRIBUTING.md](https://github.com/w3c/bp-i18n-specdev/blob/gh-pages/CONTRIBUTING.md).\n\nEditors should be familiar with and use the following:\n\n- [GitHub guidelines for working with i18n documents](https://w3c.github.io/i18n-activity/guidelines/github)\n- [Editorial guidelines for working with i18n documents](https://w3c.github.io/i18n-activity/guidelines/editing)\n\n### Links\n- [Working Group Home Page](https://w3c.github.io/i18n-activity/i18n-wg/)\n" }, "w3c": { "group": 32113, @@ -120669,7 +120681,7 @@ "body": "# Code of Conduct\n\nAll documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).\n" }, "readme": { - "text": "# VC JOSE COSE Test Suite\n\nThis project provides a flexible and extensible test suite runner for validating implementations of the specification\nfor securing [W3C Verifiable Credentials using JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and\nEncryption (COSE)](https://www.w3.org/TR/vc-jose-cose).\n\nIt's designed to work with different types of implementations (SDK or server) as long as they conform to a common CLI\ninterface via [Docker](https://www.docker.com/).\n\nThe suite makes use Digital Bazaar's [mocha-w3c-interop-reporter](https://github.com/digitalbazaar/mocha-w3c-interop-reporter).\n\n## Table of Contents\n\n1. [Project Structure](#project-structure)\n2. [Key Components](#key-components)\n3. [Adding Implementations](#adding-implementations)\n4. [Running Tests](#running-tests)\n5. [Extending the Test Suite](#extending-the-test-suite)\n6. [Docker Integration](#docker-integration)\n7. [Troubleshooting](#troubleshooting)\n\n## Project Structure\n\n```\n.\n├── implementations/\n│ ├── compose.yml\n│ ├── implementations.json\n│ └── [implementation folders]\n├── tests/\n│ ├── input/\n│ └── output/\n├── reports/\n│ ├── index.html\n│ └── suite.log\n├── test-mapping.js\n├── test-runner.js\n├── test-util.js\n└── README.md\n```\n\n## Key Components\n\n### test-mapping.js\n\nThis file defines the structure of the test suite. It exports two main objects:\n\n1. `TestResult`: An enum of possible test outcomes (success, failure, indeterminate, error).\n2. `TestMapping`: A mapping of test names to their configurations. Each test configuration includes:\n - `number`: A unique identifier for the test\n - `input_file`: The name of the input file to be used, representing:\n - For issuance, a JSON unsigned Verifiable Credential or Presentation\n - For verification, a signed Verifiable Credential or Presentation, encoded as a JWT string (JOSE), \n Base64 string (COSE), or SD-JWT string (Selective Disclosure JWT)\n - `key_file`: The name of the key file to be used, representing a Verification Method\n - `fn`: The function being tested either `issue` or `verify`\n - `disclosure_paths`: An array of paths to be disclosed in a Selective Disclosure JWT (e.g. `[\"issuer\", \"validFrom\", \"credentialSubject.id\"]`)\n - `feature`: The function being tested, one of `credential_jose`, `credential_cose`, `credential_sdjwt`, \n `presentation_jose`, `presentation_cose`, or `presentation_sdjwt`\n - `expected_result`: The expected outcome of the test\n\n### test-runner.js\n\nThis is the main test runner script. It:\n\n1. Loads the implementations and their supported features\n2. Iterates through each implementation and test\n3. Skips tests for features not supported by an implementation\n4. Runs the tests and compares the results to the expected outcomes\n5. Generates a report of the test results\n\n### test-util.js\n\nThis file contains utility functions used by the test runner:\n\n1. `generateTestResults`: Executes the Docker command to run a test for a specific implementation\n2. `checkTestResults`: Reads and interprets the results of a test execution\n\n## Adding Implementations\n\nTo add a new implementation:\n\n1. Create a new folder in the `implementations/` directory with your implementation name.\n2. Add your implementation files, including a Dockerfile that sets up your environment.\n3. Update `implementations/implementations.json` to include your new implementation and its supported features:\n\n```json\n{\n \"your-implementation-name\": {\n \"features\": {\n \"feature1\": true,\n \"feature2\": false,\n \"feature3\": true\n }\n }\n}\n```\n\nNote: if your implementation does not support a feature, set the value to `false`. This will cause the test runner to\nskip tests for that feature.\n\n4. Update `implementations/compose.yml` to include your new service:\n\n```yaml\nservices:\n your-implementation-name:\n build: ./your-implementation-name\n volumes:\n - ../tests/input:/tests/input\n - ../tests/output:/tests/output\n```\n\n## Running Tests\n\nTo run the test suite:\n\n1. Ensure Docker and [Docker Compose](https://docs.docker.com/compose/) are installed on your system.\n2. Navigate to the project root directory.\n3. Run the test runner script (the exact command may vary based on your setup, e.g., `node test-runner.js`).\n\nThere is also an npm script that can be used to run the test suite:\n\n```sh\nnpm run test\n```\n\nThe test runner will execute each test for each implementation and generate a report in the `reports/` directory.\n\n## Extending the Test Suite\n\nTo add new tests:\n\n1. Add any necessary input files to the `tests/input/` directory.\n2. Update `test-mapping.js` to include the new test configurations.\n3. If testing a new feature, ensure implementations are updated to declare support (or lack thereof) for the new feature.\n\n## Docker Integration\n\nEach implementation should provide a Docker container that exposes a CLI with the following interface:\n\n```\nvalidate --input --config '' --output \n```\n\n- ``: Path to the input file within the container\n- ``: JSON string containing test configuration\n- ``: Path where the output should be written within the container\n\nThe Docker containers are run using Docker Compose, with volumes mounted to provide access to the input and output directories.\n\nThis configuration setup is designed to be flexible and can be modified to suit the specific requirements of each implementation,\nthough it can be modified to suit the specific requirements of a given test suite.\n\n## Troubleshooting\n\nIf you encounter issues:\n\n1. Check the console output for error messages.\n2. Verify that all necessary files exist in the expected locations.\n3. Ensure Docker containers have the necessary permissions to read input and write output.\n4. Check that implementations correctly handle the provided CLI arguments.\n\nFor more detailed debugging:\n- Add console.log statements in the test runner or utility functions.\n- Inspect the Docker container logs for implementation-specific issues.\n\n---\n\nFor any questions or issues not covered in this README, please open an issue in the project repository.\n" + "text": "# VC JOSE COSE Test Suite\n\nThis project provides a flexible and extensible test suite runner for validating implementations of the specification\nfor securing [W3C Verifiable Credentials using JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and\nEncryption (COSE)](https://www.w3.org/TR/vc-jose-cose).\n\nIt's designed to work with different types of implementations (SDK or server) as long as they conform to a common CLI\ninterface via [Docker](https://www.docker.com/).\n\nThe suite makes use Digital Bazaar's [mocha-w3c-interop-reporter](https://github.com/digitalbazaar/mocha-w3c-interop-reporter).\n\n## Table of Contents\n\n1. [Project Structure](#project-structure)\n2. [Key Components](#key-components)\n3. [Adding Implementations](#adding-implementations)\n4. [Running Tests](#running-tests)\n5. [Extending the Test Suite](#extending-the-test-suite)\n6. [Docker Integration](#docker-integration)\n7. [Troubleshooting](#troubleshooting)\n\n## Project Structure\n\n```\n.\n├── implementations/\n│ ├── compose.yml\n│ ├── implementations.json\n│ └── [implementation folders]\n├── tests/\n│ ├── input/\n│ └── output/\n├── reports/\n│ ├── index.html\n│ └── suite.log\n├── test-mapping.js\n├── test-runner.js\n├── test-util.js\n└── README.md\n```\n\n## Key Components\n\n### test-mapping.js\n\nThis file defines the structure of the test suite. It exports two main objects:\n\n1. `TestResult`: An enum of possible test outcomes (success, failure, indeterminate, error).\n2. `TestMapping`: A mapping of test names to their configurations. Each test configuration includes:\n - `number`: A unique identifier for the test\n - `input_file`: The name of the input file to be used, representing:\n - For issuance, a JSON unsigned Verifiable Credential or Presentation (a .json file)\n - For verification, a signed Verifiable Credential or Presentation, encoded as a JWT string (JOSE), \n Base64 string (COSE), or SD-JWT string (Selective Disclosure JWT) (a .txt file)\n - `key_file`: The name of the key file to be used, representing a Verification Method (a .json file)\n - `fn`: The function being tested either `issue` or `verify`\n - `disclosure_paths`: An array of paths to be disclosed in a Selective Disclosure JWT (e.g. a JSON array like \n `[\"issuer\", \"validFrom\", \"credentialSubject.id\"]`)\n - `feature`: The function being tested, one of `credential_jose`, `credential_cose`, `credential_sdjwt`, \n `presentation_jose`, `presentation_cose`, or `presentation_sdjwt`\n - `expected_result`: The expected outcome of the test written to a file of the following format:\n \n ```json\n {\n \"result\": \"success\",\n \"data\": \"...\"\n }\n ```\n Where `result` is one of `success`, `failure`, `indeterminate`, or `error`, and `data` is a string containing a \n signed and encoded credential or presentation.\n\n### test-runner.js\n\nThis is the main test runner script. It:\n\n1. Loads the implementations and their supported features\n2. Iterates through each implementation and test\n3. Skips tests for features not supported by an implementation\n4. Runs the tests and compares the results to the expected outcomes\n5. Generates a report of the test results\n\n### test-util.js\n\nThis file contains utility functions used by the test runner:\n\n1. `generateTestResults`: Executes the Docker command to run a test for a specific implementation\n2. `checkTestResults`: Reads and interprets the results of a test execution\n\n## Adding Implementations\n\nTo add a new implementation:\n\n1. Create a new folder in the `implementations/` directory with your implementation name.\n2. Add your implementation files, including a Dockerfile that sets up your environment.\n3. Update `implementations/implementations.json` to include your new implementation and its supported features:\n\n```json\n{\n \"your-implementation-name\": {\n \"features\": {\n \"feature1\": true,\n \"feature2\": false,\n \"feature3\": true\n }\n }\n}\n```\n\nNote: if your implementation does not support a feature, set the value to `false`. This will cause the test runner to\nskip tests for that feature.\n\n4. Update `implementations/compose.yml` to include your new service:\n\n```yaml\nservices:\n your-implementation-name:\n build: ./your-implementation-name\n volumes:\n - ../tests/input:/tests/input\n - ../tests/output:/tests/output\n```\n\n## Running Tests\n\nTo run the test suite:\n\n1. Ensure Docker and [Docker Compose](https://docs.docker.com/compose/) are installed on your system.\n2. Navigate to the project root directory.\n3. Run the test runner script (the exact command may vary based on your setup, e.g., `node test-runner.js`).\n\nThere is also an npm script that can be used to run the test suite:\n\n```sh\nnpm run test\n```\n\nThe test runner will execute each test for each implementation and generate a report in the `reports/` directory.\n\n## Extending the Test Suite\n\nTo add new tests:\n\n1. Add any necessary input files to the `tests/input/` directory.\n2. Update `test-mapping.js` to include the new test configurations.\n3. If testing a new feature, ensure implementations are updated to declare support (or lack thereof) for the new feature.\n\n## Docker Integration\n\nEach implementation should provide a Docker container that exposes a CLI with the following interface:\n\n```\nvalidate --input --config '' --output \n```\n\n- ``: Path to the input file within the container\n- ``: JSON string containing test configuration\n- ``: Path where the output should be written within the container\n\nThe Docker containers are run using Docker Compose, with volumes mounted to provide access to the input and output directories.\n\nThis configuration setup is designed to be flexible and can be modified to suit the specific requirements of each implementation,\nthough it can be modified to suit the specific requirements of a given test suite.\n\n## Troubleshooting\n\nIf you encounter issues:\n\n1. Check the console output for error messages.\n2. Verify that all necessary files exist in the expected locations.\n3. Ensure Docker containers have the necessary permissions to read input and write output.\n4. Check that implementations correctly handle the provided CLI arguments.\n\nFor more detailed debugging:\n- Add console.log statements in the test runner or utility functions.\n- Inspect the Docker container logs for implementation-specific issues.\n\n---\n\nFor any questions or issues not covered in this README, please open an issue in the project repository.\n" }, "w3c": { "group": [ @@ -159287,6 +159299,75 @@ ] } }, + { + "id": "R_kgDONeePsA", + "name": ".github", + "owner": { + "login": "w3ctag" + }, + "isArchived": false, + "homepageUrl": null, + "description": "Github configuration repository", + "isPrivate": false, + "createdAt": "2024-12-16T18:49:15Z", + "labels": [ + { + "name": "bug", + "color": "d73a4a" + }, + { + "name": "documentation", + "color": "0075ca" + }, + { + "name": "duplicate", + "color": "cfd3d7" + }, + { + "name": "enhancement", + "color": "a2eeef" + }, + { + "name": "good first issue", + "color": "7057ff" + }, + { + "name": "help wanted", + "color": "008672" + }, + { + "name": "invalid", + "color": "e4e669" + }, + { + "name": "question", + "color": "d876e3" + }, + { + "name": "wontfix", + "color": "ffffff" + } + ], + "defaultBranch": { + "name": "main" + }, + "environments": { + "nodes": [] + }, + "branchProtectionRules": { + "nodes": [] + }, + "w3cjson": null, + "prpreviewjson": null, + "autoPublish": null, + "travis": null, + "contributing": null, + "license": null, + "codeOfConduct": null, + "readme": { + "text": "# .github\nGithub configuration repository\n" + } + }, { "id": "MDEwOlJlcG9zaXRvcnkyNjcyNjI5MTg=", "name": "accessibility-questionnaire", @@ -163206,6 +163287,90 @@ "text": "# urls-in-data\n" } }, + { + "id": "R_kgDONeecHg", + "name": "user-agents", + "owner": { + "login": "w3ctag" + }, + "isArchived": false, + "homepageUrl": "https://w3ctag.github.io/user-agents/", + "description": "A Draft Finding on User Agents", + "isPrivate": false, + "createdAt": "2024-12-16T18:57:44Z", + "labels": [ + { + "name": "bug", + "color": "d73a4a" + }, + { + "name": "documentation", + "color": "0075ca" + }, + { + "name": "duplicate", + "color": "cfd3d7" + }, + { + "name": "enhancement", + "color": "a2eeef" + }, + { + "name": "good first issue", + "color": "7057ff" + }, + { + "name": "help wanted", + "color": "008672" + }, + { + "name": "invalid", + "color": "e4e669" + }, + { + "name": "question", + "color": "d876e3" + }, + { + "name": "wontfix", + "color": "ffffff" + } + ], + "defaultBranch": { + "name": "main" + }, + "environments": { + "nodes": [ + { + "name": "github-pages" + } + ] + }, + "branchProtectionRules": { + "nodes": [] + }, + "w3cjson": null, + "prpreviewjson": { + "text": "{\n \"src_file\": \"index.bs\",\n \"type\": \"bikeshed\",\n \"params\": {\n \"force\": 1\n }\n}\n" + }, + "autoPublish": null, + "travis": null, + "contributing": null, + "license": { + "text": "All documents in this Repository are licensed by contributors\nunder the\n[W3C Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software).\n" + }, + "codeOfConduct": null, + "readme": { + "text": "# User Agents\n\nThe web fundamentally depends on user agents that help people access websites. We currently have a\ntechnical definition in [Infra](https://infra.spec.whatwg.org/#user-agent), which drew on previous\ndefinitions in [RFC2616](https://datatracker.ietf.org/doc/html/rfc2616#section-1.3),\n[CSS](https://www.w3.org/TR/CSS2/conform.html#user-agent),\n[UAAG](https://www.w3.org/TR/UAAG20/#def-user-agent), and https://en.wikipedia.org/wiki/User_agent.\nWe also have guidelines for user-agent behavior in the [Privacy\nPrinciples](https://w3ctag.github.io/privacy-principles/#user-agents), even though they're not\nprimarily about privacy. This Draft Finding attempts to unify the W3C's and WHATWG's descriptions of\nuser agents in a single authoritative place.\n\n## Building\n\nYou have 2 options:\n\n1. Run `make` or\n2. Install Bikeshed using the instructions at https://speced.github.io/bikeshed/#install-normal, and\n then use `bikeshed spec`, `bikeshed watch`, or `bikeshed serve` to build the Finding.\n\n## Contributing\n\nFollow the [code of conduct](https://www.w3.org/policies/code-of-conduct/), and then feel free to\nsuggest changes by filing and commenting on issues and pull requests.\n" + }, + "prpreview": { + "src_file": "index.bs", + "type": "bikeshed", + "params": { + "force": 1 + } + } + }, { "id": "R_kgDOM0N7IQ", "name": "w3ctagbot", @@ -198950,6 +199115,10 @@ }, "fullshortname": "other/tag", "repos": [ + { + "name": ".github", + "fullName": "w3ctag/.github" + }, { "name": "accessibility-questionnaire", "fullName": "w3ctag/accessibility-questionnaire" @@ -199094,6 +199263,10 @@ "name": "urls-in-data", "fullName": "w3ctag/urls-in-data" }, + { + "name": "user-agents", + "fullName": "w3ctag/user-agents" + }, { "name": "w3ctagbot", "fullName": "w3ctag/w3ctagbot" @@ -200967,6 +201140,66 @@ } ] }, + "73865": { + "id": 73865, + "name": "Data Shapes Working Group", + "is_closed": false, + "description": "The mission of the Data Shapes Working Group is to update data shapes standards in line with the versions of core Semantic Web standards that cater for RDF-star and to extend the applications of data shapes with new packaging and use specifications.", + "shortname": "data-shapes", + "discr": "w3cgroup", + "_links": { + "self": { + "href": "https://api.w3.org/groups/wg/data-shapes" + }, + "homepage": { + "href": "https://www.w3.org/groups/wg/data-shapes/" + }, + "users": { + "href": "https://api.w3.org/groups/wg/data-shapes/users" + }, + "services": { + "href": "https://api.w3.org/groups/wg/data-shapes/services" + }, + "specifications": { + "href": "https://api.w3.org/groups/wg/data-shapes/specifications" + }, + "chairs": { + "href": "https://api.w3.org/groups/wg/data-shapes/chairs" + }, + "team-contacts": { + "href": "https://api.w3.org/groups/wg/data-shapes/teamcontacts" + }, + "charters": { + "href": "https://api.w3.org/groups/wg/data-shapes/charters" + }, + "active-charter": { + "href": "https://api.w3.org/groups/wg/data-shapes/charters/525" + }, + "join": { + "href": "https://www.w3.org/groups/wg/data-shapes/join" + }, + "pp-status": { + "href": "https://www.w3.org/groups/wg/data-shapes/ipr" + }, + "participations": { + "href": "https://api.w3.org/groups/wg/data-shapes/participations" + } + }, + "type": "working group", + "start-date": "2014-09-30", + "end-date": "2026-12-31", + "fullshortname": "wg/data-shapes", + "repos": [ + { + "name": "data-shapes", + "fullName": "w3c/data-shapes" + }, + { + "name": "shacl", + "fullName": "w3c/shacl" + } + ] + }, "74168": { "id": 74168, "name": "Second Screen Working Group",