diff --git a/README.md b/README.md index 400d59c..aeea843 100644 --- a/README.md +++ b/README.md @@ -5,11 +5,11 @@ The following describes how changes to the specifications in the Solid ecosystem Development in the Solid ecosystem occurs in the [Solid Specifications](https://github.com/solid/specification) repository. The deprecated [Unofficial Draft](https://github.com/solid/solid-spec) predating current development is still available for historical reference. -Anyone may participate in this process. Please read the [Code of Conduct](code-of-conduct.md) before doing so. +Anyone may participate in this process. Please read the [Code of Conduct](committees/code-of-conduct/code-of-conduct.md) before doing so. ## Editorial Team -The Solid [Editorial Team](https://github.com/orgs/solid/teams/editors) is responsible for the implementation of the Solid Specification process. Members of the Editorial Team are appointed by the Solid Director. The Editorial Team is comprised of all the Editors appointed by the Solid Director, who are listed at [editors.md](editors.md), along with their assignments, contact details, and affiliations. The Editorial Team shepherds Solid and coordinates with those who participate in [Solid Panels](#solid-panels) and with [Stakeholders](#stakeholders) and [Implementers](#implementers). The Solid Director may also appoint support personnel on an as-needed basis, such as a Release Manager, for organizing the workflow of the specification process. +The Solid [Editorial Team](https://github.com/orgs/solid/teams/editors) is responsible for the implementation of the Solid Specification process. Members of the Editorial Team are appointed by the Solid Director. The Editorial Team is comprised of all the Editors appointed by the Solid Director, who are listed at [editors.md](committees/editors/editors.md), along with their assignments, contact details, and affiliations. The Editorial Team shepherds Solid and coordinates with those who participate in [Solid Panels](#solid-panels) and with [Stakeholders](#stakeholders) and [Implementers](#implementers). The Solid Director may also appoint support personnel on an as-needed basis, such as a Release Manager, for organizing the workflow of the specification process. Anyone may apply to be an Editor, and must include one or more requested editorial assignments as part of their application. These requests are reviewed only by the Solid Director. Editor applications that can demonstrate the support of a relevant panel or group of community members will be favorably considered. @@ -87,7 +87,7 @@ A draft proposal often involves public discussion before being formally presente Candidate proposals to the [Solid Specification](https://github.com/solid/specification) submitted for review go through an editorial process before they are accepted. -The [Solid Editors](https://github.com/orgs/solid/teams/editors) [maintain a monthly development cycle](solid-editors-tr-process.md) in which they select proposals and issues from the open issues and proposals for consideration. +The [Solid Editors](https://github.com/orgs/solid/teams/editors) [maintain a monthly development cycle](committees/editors/solid-editors-tr-process.md) in which they select proposals and issues from the open issues and proposals for consideration. The Editors typically meet weekly, with an agenda put forward by the Solid Director with the help of other Editors and the Release Manager. In the interest of transparency, these meetings are to be recorded and made public within two days of the meeting. @@ -127,7 +127,11 @@ Editors have [_Admin Permissions_](https://help.github.com/en/articles/repositor # Administration -Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid. This includes the [Solid GitHub](https://github.com/solid) organization, [Solid Gitter](https://gitter.im/solid/home) channels, the [Solid Forum](https://forum.solidproject.org), and the [Solid Website](https://www.solidproject.org). +Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid. They are tasked with maintaining and updating the following: + - [Solid GitHub](https://github.com/solid) organization + - [Solid Gitter](https://gitter.im/solid/home) channels + - [Solid Forum](https://forum.solidproject.org) + - [Solid Website](https://www.solidproject.org). Administrators belong to the [Administrators Team](https://github.com/orgs/solid/teams/administrators) in the [Solid GitHub Organization](https://github.com/solid) and have [_Admin Permissions_](https://help.github.com/en/articles/repository-permission-levels-for-an-organization#permission-levels-for-repositories-owned-by-an-organization) on all repositories therein. Administrators have [_Owner Permissions_](https://help.github.com/en/articles/permission-levels-for-an-organization#permission-levels-for-an-organization) for the [Solid GitHub Organization](https://github.com/solid). @@ -135,12 +139,10 @@ The Solid World Coordination Administrator is granted privileged access to such ### Becoming an Administrator -Administrators are appointed by the Solid Director. Administrators are listed at [administrators.md](administrators.md) along with their contact details and affiliations. Anyone may apply to be an Administrator. Administrator applications are reviewed only by the Solid Director. +Administrators are appointed by the Solid Director. Administrators are listed at [administrators.md](committees/administrators/administrators.md) along with their contact details and affiliations. Anyone may apply to be an Administrator. Administrator applications are reviewed only by the Solid Director. # Solidproject.org Website -[Creators](https://github.com/solid/process/blob/master/creators.md) independently assist with keeping [solidproject.org](https://solidproject.org/) up to date. - Anyone can make suggestions by creating issues or submitting pull requests to the [solid/solidproject.org](https://github.com/solid/solidproject.org) repository. diff --git a/administrators.md b/committees/administrators/administrators.md similarity index 77% rename from administrators.md rename to committees/administrators/administrators.md index 4dc68bc..dd4bb11 100644 --- a/administrators.md +++ b/committees/administrators/administrators.md @@ -1,6 +1,6 @@ # Solid Administrators -Below is a listing of [Solid Administrators](README.md#administration). Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid Specification, Solid Roadmap, and Supporting Documentation. +Below is a listing of [Solid Administrators](../../README.md#administration). Administrators are granted privileged access to control the tools, systems, and services used for advancing the Solid Specification, Solid Roadmap, and Supporting Documentation. | Name | WebID | | --------- | ---------- | diff --git a/code-of-conduct.md b/committees/code-of-conduct/code-of-conduct.md similarity index 100% rename from code-of-conduct.md rename to committees/code-of-conduct/code-of-conduct.md diff --git a/dei-team.md b/committees/dei/dei-team.md similarity index 100% rename from dei-team.md rename to committees/dei/dei-team.md diff --git a/editors.md b/committees/editors/editors.md similarity index 95% rename from editors.md rename to committees/editors/editors.md index 10d2b3e..08356d0 100644 --- a/editors.md +++ b/committees/editors/editors.md @@ -1,6 +1,6 @@ # Solid Editors -Below is a listing of the Solid Editorial Team and their respective assignments. See [Reviewing Proposals](README.md#reviewing-proposals.md) for an explanation of how the editorial process is used to review and accept changes to Solid Specifications, the Solid Roadmap, and Supporting Documentation. +Below is a listing of the Solid Editorial Team and their respective assignments. See [Reviewing Proposals](../../README.md#reviewing-proposals.md) for an explanation of how the editorial process is used to review and accept changes to Solid Specifications, the Solid Roadmap, and Supporting Documentation. ## Editorial Team diff --git a/solid-editors-tr-phases.svg b/committees/editors/solid-editors-tr-phases.svg similarity index 100% rename from solid-editors-tr-phases.svg rename to committees/editors/solid-editors-tr-phases.svg diff --git a/solid-editors-tr-process.md b/committees/editors/solid-editors-tr-process.md similarity index 100% rename from solid-editors-tr-process.md rename to committees/editors/solid-editors-tr-process.md diff --git a/creators.md b/creators.md deleted file mode 100644 index 8b99920..0000000 --- a/creators.md +++ /dev/null @@ -1,11 +0,0 @@ -Below is a record of the Creators who are appointed by the Solid Director. - -| Name | WebID | -| --------- | ---------- | -| [Jeff Zucker](https://github.com/jeff-zucker) | https://jeff-zucker.solidcommunity.net/profile/card#me | -| Vincent Tunru | https://vincentt.inrupt.net/profile/card#me | -| Nicolas S. | https://solid.zwifi.eu/profile/card#me | -| [Kay Kim](https://github.com/kay-kim) | https://kay.inrupt.net/profile/card#me | -| [Ted Thibodeau](https://github.com/TallTed) | http://id.myopenlink.net/dataspace/person/tthibodeau#this | -| [Kyra Assaad](https://github.com/kyraassaad) | https://pod.inrupt.com/kyra/profile/card#me | -| [Virginia Balseiro](https://github.com/VirginiaBalseiro) | https://virginia.solidcommunity.net/profile/card#me | diff --git a/draft-working-group-charter/charter-style.css b/draft-working-group-charter/charter-style.css deleted file mode 100644 index 551b783..0000000 --- a/draft-working-group-charter/charter-style.css +++ /dev/null @@ -1,89 +0,0 @@ -#template h1 { clear: none } - -form { width: 90%; - background: #eee5de; - color: black; - border: thin black solid; - padding: .5em; - margin-bottom: 1em; - margin-left: auto; - margin-right: auto - } - -body { counter-reset: h2; } - -h2.nocount:before { content: "" } - -h2:before { - content: counter(h2) ". "; - display: inline; - } - -h2.nocount { - counter-increment: none; - counter-reset: none - } - -h2 { - counter-increment: h2; - counter-reset: h3; - } - -h3:before { - content: counter(h2) "." counter(h3) " "; - display: inline; - } - -h3 { counter-increment: h3; } - -h4 { margin-left: 0 } - -tfoot -{ - font-size: 0.9em; - font-style: italic; - background-color: #ddd; -} - -td.meeting { background: #FFE } -td.WD1 { background: #FED } -td.LC { background: #FCB } -td.CR { background: #FA9 } -td.PR { background: #F87 } -td.REC { background: #F60 } -td.note { background: #F60 } - -.toadd { background-color: #FF0; font-style: italic} - -strong.must { color: #F30; } - -strong.should { color: #C63; padding: 0; border: none } -.should { - padding: .25em; - border: thin #C63 solid; - } - -li.may, strong.may { color: #99C; } -div.may { - padding: 3px; - background-color: #e2edfe; - border: 1px #005A9C solid; } - -.example -{ - background-color: #CC9; -} - -div.example, ul.example, p.example, ol.example -{ - width: 80%; - border: thin black solid; -} - -@media print { - .noprint { display: none } -} - -.todo { - background-color:#FFC; -} \ No newline at end of file diff --git a/draft-working-group-charter/index.html b/draft-working-group-charter/index.html deleted file mode 100644 index 42da5da..0000000 --- a/draft-working-group-charter/index.html +++ /dev/null @@ -1,608 +0,0 @@ - - - - - - W3C Solid Working Group Charter DRAFT-BR-2023-01-23 - - - - - - - - - - - -
-

Solid Working Group Charter

- -

- Cloud services in use on the Web today (2023) often require users to store their data and place control over that data at a third-party cloud provider. Solid adds to existing Web standards to enable user control: to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs. Solid defines the notion of Pods, in which users place their own data and control access to that data, and a suite of interoperable protocols for managing Pods, applications that use pods, and interactions with existing protocols for authentication. - - Solid presents several advantages over more traditional architectures for data use by Web services today, including: -

- - - -

- W3C Members that would like to learn more about the motivations that led to this work may find the About Solid page useful. The Solid project consists of a draft specification and a suite of implementations, tools, and libraries for developers. -

- -

- The mission of the Solid Working Group (LINK TBD) is to standardize the Solid Protocol and its use of associated data interoperability and authentication schemes. This effort will culminate in open standards that can be used by developers of servers and applications to continue to build a rich ecosystem that returns control of data back to users. -

- -
-

- Join the Solid Working Group (LINK TBD). -

-
- -
- - - - - - - - - - - - - - - - - - - - - - -
- Start date - - DD Month YYYY -
- End date - - DD Month YYYY -
- Chairs - - Ruben Verborgh (imec)
- Justin Bingham (Janeiro Digital)
- Aaron Coburn (Inrupt) -
- Team Contact - - Pierre-Antoine Champin (0.1 FTE) -
- Meeting Schedule - - Teleconferences: 1-hour calls will be held bi-weekly -
- Face-to-face: we will meet -during the W3C's annual Technical Plenary week; additional face-to-face -meetings may be scheduled by consent of the participants, usually no -more than 3 per year. -
-
- -
-

Scope

- -

- The design approach for the Solid specification will continue substantial efforts undertaken previously in the Solid community to specify a set of interoperable protocol standards for enabling the use and development of Solid Pods and applications across a wide range of use cases. -

- -

- The Working Group will: -

-
    -
  1. - Define a core protocol specification for the secure and efficient operation of Solid servers and the behavior of clients interacting with those servers. -
    2. -
  2. - Recommend a data and protocol model for interoperability between multiple applications built upon Solid. -
    3. -
  3. - Recommend a set of practices needed for data security for Solid Pods, and for both server and client software, including use of appropriate authentication, authorization, verification, identity, and other standards, integrating existing outside efforts. -
    4. -
  4. - Recommend a set of protocol behaviors and best practices for the use in Solid of the OpenID Connect (OIDC) / Federation identity layer on top of the OAuth 2.0 protocol. -
    5. -
  5. - Recommend a set of protocol behaviors and best practices to request and grant access to data stored in Solid Pods. -
    6. -
  6. - Define a protocol for state synchronization regarding changes to resources in Solid pods. -
    7. -
- -
-

Out of Scope

-

- The following features and topics are out of scope and will not be addressed by this Working Group. -

- -
    -
  • - Definition of identity mechanisms such as WebID and DID -
    • -
  • - Definition of linked data formats -
    • -
-
- -
-

Success Criteria

-

- In order to advance to the status of - Proposed Recommendation, each specification will fulfill the - implementation experience required by the W3C Process as follows: -

- -
    -
  • - The Working Group will seek evidence of independent interoperable uses of the Solid protocol from at least two independent implementations of each feature defined in the specification. -
    • -
  • - The group will add a section detailing any known security or privacy implications for implementers, Web authors, and end users. -
    • -
  • - The group will maintain and advance a test suite (LINK TBD), which, among other goals, will enable interoperability testing. -
    • -
-
-
- -
-

- Deliverables -

-

- More detailed milestones and updated publication schedules are available on the - group publication status page (LINK TBD). -

- -
-

- Normative Specifications -

-

- The Solid Working Group will deliver the following W3C normative specifications: -

-
-
Solid Protocol v1.0
-
-

- The Solid Protocol specification aims to provide applications with secure and permissioned access to externally stored data in an interoperable way. An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access control policies, and use preferred applications and services to achieve them. -

-

- When possible, the Solid Protocol will evolve while maintaining a high degree of compatibility with existing implementations, of both servers and clients, and with features from prior versions. If incompatible changes have to be made, then they will be done by introducing a stage where both old and new protocols are supported, to allow the implementors to upgrade their systems in a managed way. -

-

- The Solid specification may include protocol details for integration with the following: -

    -
  1. - OpenID Connect -
    2. -
  2. - Access grants using W3C Verifiable Credentials -
    3. -
  3. - Identity mechanisms such as WebID and DID -
    4. -
  4. - Notifications about resource changes -
    5. -
  5. - Authorization mechanisms such as Web Access Control and Access Control Policy -
    6. -

    -
-
- -

- Note that the WG may decide, based on editorial and readability considerations, to spin off sections into separate Recommendations track specifications. -

-

- All specifications, regardless of their progress along the W3C process line from Working Draft to Recommendation, will be given a version number, such as 0.9, which will be incremented like from 0.9 to 0.10 for minor changes. A major version increment like 2.2 to 3.0 will be used if there is an incompatible change in the protocol. The required versions of each dependency will be given in each spec. -

-
- -
-

- Other Deliverables -

-

- Other non-normative documents may be created such as: -

-
-
Test Suite and Implementation Report
-
-

- The Working Group will develop a test suite and implementation report to test and document conformance levels achieved by implementors. -

-
-
-
- -
-

Timeline (TBD)

- - - - - - - - - - - - - - - - - - - - -
- Note: The group will document significant changes from this initial schedule on the group home page. -
Specification - FPWD - - CR - - PR - - Rec -
- Solid Protocol - - Month YYYY -
- -
-
- - -
-

Coordination

-

- For all specifications, this Working Group will seek horizontal review - for accessibility, internationalization, performance, privacy, and -security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including the FPWD and at least 3 months before the CR, and should be issued when major changes occur in a specification. -

- -

- Additional technical coordination with the following Groups will be made, per the W3C Process Document: -

- -
-

W3C Groups

- -
-
- Verifiable Credentials Working Group -
-
- Coordination on mechanisms for granting access to resources. -
-
- DID Working Group -
-
- Coordination on mechanisms for decentralized identifier use in Solid. -
-
- Credentials Community Group -
-
- Coordination on other specifications related to Decentralized Identifiers. -
-
- JSON-LD Working Group -
-
- Coordination to ensure that the JSON-LD syntax meets the Solid Working Group's needs. -
-
- Web Authentication Working Group -
-
- Coordination to ensure that Web Authentication primitives align with Solid principles and aims. -
-
- -
- - -
- -
-

- Participation -

-

- To be successful, this Working Group is expected to have - 6 or more active participants for its duration, including -representatives from the key implementors of this specification, and -active Editors and Test Leads for each specification. The Chairs, -specification Editors, and Test Leads are expected to contribute half of - a working day per week towards the Working Group. There is no minimum -requirement for other Participants. -

-

- The group encourages questions, comments and issues on -its public mailing lists and document repositories, as described in Communication. -

-

- W3C Members are invited to join this Working Group. Individuals who wish to participate as Invited Experts (i.e., they do not represent a W3C Member) should refer to the policy for approval of Invited Experts. - The group also welcomes non-Members to contribute technical submissions - for consideration upon their agreement to the terms of the W3C Patent Policy. -

-
- -
-

- Communication -

-

- Technical discussions for this Working Group are conducted in public: - the meeting minutes from teleconference and face-to-face meetings will -be archived for public review, and technical discussions and issue -tracking will be conducted in a manner that can be both read and written - to by the general public. Working Drafts and Editor's Drafts of -specifications will be developed on a public repository, and may permit -direct public contribution requests. The meetings themselves are not -open to public participation, however. -

-

- Information about the group (including details about -deliverables, issues, actions, status, participants, and meetings) will -be available from the Solid Working Group home page (LINK TBD). -

-

- Most Working Group -teleconferences will focus on discussion of particular specifications, -and will be conducted on an as-needed basis. -

-

- This group primarily conducts its technical work on the public mailing list public-solid-wg@w3.org (LINK TBD) ( archive (LINK TBD)) or on GitHub issues (LINK TBD) - (and specification-specific GitHub repositories and issue trackers). -The public is invited to review, discuss and contribute to this work. -

-

- The group will publish minutes for each teleconference at https://github.com/w3c/solid-wg/Meeting/Minutes/ (LINK TBD). -

-
- -
-

- Decision Policy -

-

- This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). - Typically, an editor or other participant makes an initial proposal, -which is then refined in discussion with members of the group and other -reviewers, and consensus emerges with little formal voting being -required. -

-

- However, if a decision is necessary for timely progress, - but consensus is not achieved after careful consideration of the range -of views presented, the Chairs may call for a group vote, and record a -decision along with any objections. -

-

- To afford asynchronous decisions and organizational -deliberation, any resolution (including publication decisions) taken in a - face-to-face meeting or teleconference will be considered provisional. -

-

- A call for consensus (CfC) will be issued for all -resolutions (for example, via email and/or web-based survey), with a -response period from one week to 10 working days, depending on the -chair's evaluation of the group consensus on the issue. -

-

- If no objections are raised on the mailing list by the -end of the response period, the resolution will be considered to have -consensus as a resolution of the Working Group. -

-

- All decisions made by the group should be considered -resolved unless and until new information becomes available, or unless -reopened at the discretion of the Chairs or the Director. -

-

- This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires. -

-
- -
-

- Patent Policy -

-

- This Working Group operates under the W3C Patent - Policy (Version of 15 September 2020). To -promote the widest adoption of Web standards, W3C seeks to issue -Recommendations that can be implemented, according to this policy, on a -Royalty-Free basis. -

-

- For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation. -

-
- -
-

Licensing

-

- This Working Group will use the W3C Software and Document license for all its deliverables. -

-
- -
-

- About this Charter -

-

- This charter has been created according to section 5.2 of the Process Document. - In the event of a conflict between this document or the provisions of -any charter and the W3C Process, the W3C Process shall take precedence. -

- -
-

-Charter History -

- -

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

- - - - - - - - - - - - - - - - -
Charter Period Start Date End Date Changes
Initial Charter Month YYYY Month YYYY none
-
-
-
- -
- - - diff --git a/draft-working-group-charter/pubrules-style.css b/draft-working-group-charter/pubrules-style.css deleted file mode 100644 index c71ee6d..0000000 --- a/draft-working-group-charter/pubrules-style.css +++ /dev/null @@ -1,138 +0,0 @@ -@import url("http://www.w3.org/StyleSheets/base.css"); - -/* Copyright 1997-2005 W3C (MIT, ERCIM, Keio). All Rights Reserved. - The following software licensing rules apply: - http://www.w3.org/Consortium/Legal/copyright-software */ - -/* $Id: pubrules-style.css,v 1.1 2018/01/25 15:52:23 plehegar Exp $ */ - -body { - margin: 2em 1em 2em 70px; - font-family: sans-serif; - color: black; - background-color: white; - background-position: top left; - background-attachment: fixed; - background-repeat: no-repeat; -} - -h1, h2, h3, h4, h5 { - text-align: left; - font-family: sans-serif; - font-weight: normal; - color: #005a9c; - margin-left: 0 -} - -h4, h5, blockquote { margin-left: 1em } - -div.head p { margin-left: 0 } - -.first { margin: 3em 4em 2em 3em} - -div.head img { - color: white; - border: none; - float:left; - padding-right: 1em; - padding-bottom: 1em; - margin-left: 0 -} - -p { clear: left } - -/*p, ul, ol, blockquote, dl { margin-left: 2em }*/ - -th { text-align: left } - -.rfc2119 { - text-transform: lowercase; - font-weight: bold -} - -/* Navigation styles from Eric Meyer */ -/* -http://www.complexspiral.com/events/archive/2003/seybold/cssnav.html -*/ - -/* Shared */ -li.label { - list-style: none; - margin: 0; - padding: .15em 0 .15em .5em; - border-top: 1px solid gray; - text-align: left; - color: white; - background: #0050B2; - font-weight: bold; - } - -/* highlighting and border effects */ -#navbar {float:right} -#navbar {padding: 0 1px 2em 1em; margin: 0; - font: bold 10px sans-serif; - background: white; width: 13em;} -#navbar li {list-style: none; margin: 0; border-top: 1px solid gray; - text-align: left;} -#navbar li#current {list-style: none; margin: 0; border-top: 1px solid gray; - text-align: left; background: #CCD; color: black; padding: 0.25em 0.5em 0.25em 0.75em; - border-left: 1em solid #AAB; text-decoration: none;} -#navbar li a {display: block; padding: 0.25em 0.5em 0.25em 0.75em; - border-left: 1em solid #AAB; text-decoration: none;} -/*#navbar li a:link {color: #448; }*/ -#navbar li a:visited {color: #667; } -#navbar li a:hover {border-color: #FE3; color: #FFF; background: #332;} - -/* Same for class version */ - -.navbar {float:right} -.navbar {padding: 0 1px 2em 1em; margin: 0; - font: bold 10px sans-serif; - background: white; width: 13em;} -.navbar li {list-style: none; margin: 0; border-top: 1px solid gray; - text-align: left;} -.navbar li#current {list-style: none; margin: 0; border-top: 1px solid gray; - text-align: left; background: #CCD; color: black; padding: 0.25em 0.5em 0.25em 0.75em; - border-left: 1em solid #AAB; text-decoration: none;} -.navbar li a {display: block; padding: 0.25em 0.5em 0.25em 0.75em; - border-left: 1em solid #AAB; text-decoration: none;} -/*.navbar li a:link {color: #448; }*/ -.navbar li a:visited {color: #667; } -.navbar li a:hover {border-color: #FE3; color: #FFF; background: #332;} - -/* tabbed styles */ -#navigation {padding: 3px 0; margin: 0; - border-bottom: 1px solid #778; - font: bold 10px sans-serif;} -#navigation li {list-style: none; margin: 0; - display: inline; line-height: 250%} -#navigation li a {padding: 3px 0.5em; margin-left: 3px; - border: 1px solid #778; border-bottom: none; - background: #DDE; - text-decoration: none;} -#navigation li a:link {color: #448; } -#navigation li a:visited {color: #667; } -#navigation li a:hover {color: #000; background: #AAE; - border-color: #227;} - -/* Same thing for class navigation */ -.navigation {padding: 3px 0; margin: 0; - border-bottom: 1px solid #778; - font: bold 10px sans-serif; } -.navigation li {list-style: none; margin: 0; - display: inline; line-height: 250%} -.navigation li a {padding: 3px 0.5em; margin-left: 3px; - border: 1px solid #778; border-bottom: none; - background: #DDE; - text-decoration: none;} -.navigation li a:link {color: #448; } -.navigation li a:visited {color: #667; } -.navigation li a:hover {color: #000; background: #AAE; - border-color: #227;} - - -/* "current tab" style */ -#navigation li a#current {background: white; border-bottom: 1px solid white;} -/* Same thing for class navigation */ -.navigation li a#current {background: white; border-bottom: 1px solid white;} - diff --git a/draft-working-group-charter/w3c_home.svg b/draft-working-group-charter/w3c_home.svg deleted file mode 100644 index 3924d01..0000000 --- a/draft-working-group-charter/w3c_home.svg +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/draft-working-group-charter/w3cdoc.css b/draft-working-group-charter/w3cdoc.css deleted file mode 100644 index 9f1a120..0000000 --- a/draft-working-group-charter/w3cdoc.css +++ /dev/null @@ -1,270 +0,0 @@ -a:link img, a:visited img { - border-style: none -} - -html{ - background-color: #fff; - color: #000; - margin:0; - border:0;} - -body -{ - background-color: #fff; - padding: 0em 2em; - font-family: "Gill Sans"; -} - -h4, h5, h6 {border: none;} -body.team -{ -margin:0; -border-right: 30px solid #FFEEC2; -border-left: 30px solid #FFEEC2;} - -body.team:before {content:"Team confidential"; - font-size: 2em; - color: #F00; - padding: 5px; - font-weight: bold;} - -body.ab -{ -margin:0; -border-right: 30px solid #E2EDFE; ; -border-left: 30px solid #E2EDFE;;} - -body.ab:before {content:"AB+Team confidential"; - font-size: 2em; - color: #F00; - padding: 5px; - font-weight: bold;} - -#content { background-color: #fff;} -/*quotes*/ -blockquote -{ - background: #c8e3ea; - padding: 0.5em; - border-left: #999; - border-width: 0 0 0 1px; - border-style: none none none solid; - font-family: "Gill Sans"; - font-style: italic; -} -q -{ - background: #c8e3ea; - font-family: "Gill Sans"; - font-style: italic; -} -blockquote:after { - display: block; - content: attr(cite); - text-align: right; - font-size: 0.7em; -} - -blockquote cite.title, -blockquote cite.author { - font-style: italic; - font-size: 0.8em -} -blockquote cite.title:before { - content: "-- "; -} - -/*PRE style*/ -pre -{ - padding: 0.5em; - border-color: #c8e3ea; - border-width: 1px 1px 1px 3px; - border-style: solid; - font-family: "Courier", fixed; -} - -/*From http://www.w3.org/2005/09/table.css*/ -table -{ - border-collapse: collapse; - margin: 1em auto; -} - -table caption -{ - margin-left: auto; - margin-right: auto; -} - -table, tr, th, td { border: 1px solid black; } -th, td { padding: 5px 1em; } - -th -{ - background: #005a9c; - color: #fff; -} - -th a:link { - color: #fff; -} - -th a:visited { - color: #aaa; -} - -#Icons { float: right; } - -#footer -{ - border-color: #333; - border-width: 1px 0 0 0; - border-style: solid none none none; - clear: both; - font-size: 0.9em; -} - -/* Stolen from /Stylesheets/activities.css */ -ul#Navigate { font-size: 0.86em; } -#Icons img { vertical-align: top; } -.trail { vertical-align: bottom; } - -.boldblack -{ - font-weight: bold !important; - background: transparent; - color: #000 !important; -} - -/* right column */ -#Contents -{ - float: left; - width: 70%; - margin: 0 1% 1em 4%; -} - -h1, h2, h3, h4, h5, h6 -{ - margin-bottom: 0; - padding-bottom: 0.15em; - border-bottom: 1px solid #ccc; - background: transparent; - color: #005a9c; - font-weight: normal; -} - -h1 -{ - margin-top: 1em; - margin-bottom: 0; - padding-bottom: 0.15em; - border-bottom: none; - background: transparent; - color: #000; -} - -p.firstelement, table, address { margin-top: 0.7em; } - -/* left column */ -ul#Navigate, ul.nav -{ - margin: 0; - padding: 0.2em 0 0 0; -} - -ul#Navigate -{ - float: left; - width: 13em; - margin: 1em 0 0 0.2em; - border-right: 1px solid gray; - background: #c8e3ea; - color: #000; - text-indent: 2px; -} - -ul#Navigate li, ul.nav li -{ - padding: 0.2em 0 0.2em 0.3em; - list-style: none; - font-weight: normal; -} - -ul.nav li { border-top: 1px solid gray; } - -ul#Navigate a, ul.nav li a -{ - padding-right: 0.1em; - background: transparent; - color: #000; - text-decoration: none; -} - -ul#Navigate li.navcurrent, ul.nav li.navcurrent -{ - list-style: disc; - background: #fff; - color: #000; -} - -ul#Navigate li a:hover, .nav li a:hover, -ul#Navigate li a:focus, .nav li a:focus -{ - background: transparent; - color: #00e; - text-decoration: underline; -} - -/* print */ - -@media print -{ - body, html { font-family: sans-serif; } - - h1, h2, h3, h4, h5, h6 - { - page-break-after: avoid; - page-break-inside: avoid; - } - - blockquote, pre, table { page-break-inside: avoid; } - ul, ol, dl { page-break-before: avoid; } - .whiteout, .trail, ul#Navigate, p#Validate { display: none; } - - div#Contents - { - float: none; - width: 100%; - } -} - -.whiteout, .whiteout a:link, .whiteout a:visited -{ - background: #fff; - color: #fff; -} - -.whiteout a:hover, .whiteout a:focus -{ - background: #fff; - color: #00e; -} - -.whiteout a:active -{ - background: #fff; - color: #f00; -} - -div.whiteout -{ - margin: -10px 0 0 0; - padding: 0; -} - -/*#status { - padding: .5em 2em; - background-color: #FCC; - margin: 0 auto;}*/ \ No newline at end of file diff --git a/librarians.md b/librarians.md deleted file mode 100644 index 9f8a832..0000000 --- a/librarians.md +++ /dev/null @@ -1,13 +0,0 @@ - -| Name | GitHub Handle | -| --------- | ---------- | -| Joachim vH | @joachimvh | -| Ruben T | @rubensworks | -| Pieter Hayvaer | @pheyvaer | -| --------- | @mielvds | -| --------- | @RubenVerborgh | - - - - - diff --git a/notifications-panel-charter.md b/notifications-panel-charter.md deleted file mode 100644 index 180325a..0000000 --- a/notifications-panel-charter.md +++ /dev/null @@ -1,143 +0,0 @@ -# Notifications Panel Charter - -The mission of the Notifications Panel as part of the W3C Solid Community Group is to extend or define technical protocols and vocabularies to facilitate notification exchange on the Open Web Platform. - -* Start date: 2021-09-13 -* End date: 2022-12-31 -* Charter extension: The charter extension history is documented in "About this charter". -* Confidentiality: Proceedings are Public -* Chair: [Sarven Capadisli](https://csarven.ca/#i) -* Team Contact: Solid Editors -* Usual Meeting Schedule: Teleconferences: Weekly, although the chair may call for topic-specific calls in addition when needed and may change working mode as work progresses. - -## Goals - -The Notifications Panel will create technical reports that standardise protocols and vocabularies for exchanging information as notifications. This should allow Web application developers to embed and facilitate access to social communication on the Web. The panel will explore use cases and requirements pertaining to activities in the Solid ecosystem; identify how existing specifications, including their specialisations and extensions, can be reused; as well as develop new specifications. The work will be driven and refined by implementation experience. The panel will collaborate with other Solid panels and may take on or pass on challenges. - -There are a number of use cases that the work of this panel will enable, including but not limited to: - -* User control of personal data: Some users would like to have autonomous control over their own social data, and share their data selectively across various systems. -* Activity subscriptions: Actors in the system may want information sent to them about particular data or when certain events or activities take place. -* Resource Access: Access to resources or services to request permission (in order to perform operations). -* Service Actions: Such as activate services, create resources, create/update/delete user accounts, migrate pods, archive pods, or delegate agents to perform tasks. - - -## Scope - -The panel within the framework of the W3C Solid CG and the Solid Project will determine the use cases that derive the requirements for the deliverables. Features that are not implemented due to time constraints can be put into a non-normative "roadmap" document for future work. The scope will include: - -* A transfer syntax for data such as activities should include at least the ability to describe the data using URIs in an extensible manner, time-stamping, and a serialization compatible with the RDF language. - -* A protocol for exchanging social data should include at least the ability to share notifications using the transfer syntax developed by the Notifications Panel or extend syntaxes such as Activity Streams 2.0. This protocol may allow the capture of new data, the verification of data using techniques such as as digital signatures, server to server interactions, and the use of groups with some form of access control or capabilities. - -* Documentation detailing upgrade paths for existing technical reports or notes, including, but not limited to, upgrading deprecated insecure WebSockets to secured WebSockets. - -Other components necessary for building federated/decentralized social Web systems are in scope but will not lead to a recommendation without re-chartering, and should be discussed in the Notifications Panel. - -### Success Criteria - -In order to advance to technical report, the specification is expected to have two independent interoperable implementations of each feature defined in the specification. Independent implementations are developed by different parties and cannot share, reuse, or be derived from code of another qualifying implementation which is directly pertinent to the implementation of this specification. - -## Deliverables - -### Normative Deliverables - -The panel will deliver the following to fulfill its goals, subject to discussion in the Solid CG: - -* Notification Protocol -* Notification Syntax - -Each of these technologies should not be tightly-coupled but can allow general purpose use. Each specification must contain a section detailing any known security and privacy implications for implementers, Web authors, and end users. The Notifications Panel will actively seek an open security and privacy review for every normative deliverable. - -### Other Deliverables - -The panel will deliver other non-normative documents, such as the following: - -* A Use Cases and Requirements document defining how features in each specification relate to concrete use-cases. -* Test Suites for normative deliverables. -* Upgrade Notes - -The panel may also deliver the following: - -* Primer or Best Practice documents to support Web developers when designing Solid applications. - -### Milestones - -The production of the deliverables depends upon the resources available, and will change as new information and implementation experience is reported to the group. The most up-to-date timeline is available from the Solid CG page. - -| Specification | ~FPWD | ~LC | ~CR | ~PR | ~Rec | -|---------------|---------|---------|---------|---------|---------| -| x | 2021-Q4 | 2022-Q1 | 2022-Q2 | 2022-Q3 | 2022-Q4 | - -Note: The Notifications Panel as part of the W3C Solid CG does not publish technical reports under the W3C Recommendation track. Thus, the milestones in the table above that are prefixed with "~" only communicate rough equivalence in maturity level of the technical reports according to section 6.2.1 of the W3C Process. - -## Coordination - -Technical coordination with the following Groups may be required: - -### W3C Groups - -* [Consent CG](https://www.w3.org/groups/cg/consent) -* [Credentials CG](https://www.w3.org/groups/cg/credentials) -* [JSON-LD WG](https://www.w3.org/groups/wg/json-ld) -* [Privacy CG](https://www.w3.org/groups/cg/privacycg) -* [RDF-DEV CG](https://www.w3.org/groups/cg/rdf-dev) -* [Social Web Incubator CG](https://www.w3.org/groups/cg/socialcg) -* [Web Applications WG](https://www.w3.org/groups/wg/webapps) - -Furthermore, the Notifications Panel expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them: - -* [Architecture of the World Wide Web, Volume I](https://www.w3.org/TR/webarch/) -* [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications) -* [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/) - -### External Groups - -* TBD - -## Participation - -Membership in the W3C Solid CG is required to participate in the Notifications Panel. All work and communication within the Solid CG is covered by the [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) as well as the [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). - -To be successful, the Notifications Panel is expected to have 10 or more active participants for its duration and to have the participation of industry leaders in fields relevant to the specifications it produces. The Chairs and specification Editors are expected to contribute one to two days per week towards the Panel. The Chair may call occasional meetings consistent with the W3C Process requirements for meetings. There is no minimum requirement for other Participants. - -The Notifications Panel will also allocate the necessary resources for building test suites for each specification. - -The group encourages questions and comments on its project repository, as described in Communication. - -## Communication - -Most Notifications Panel Teleconferences will be conducted on an as-needed basis. Normally, at least one teleconference will be held per week. - -Most of the technical work of the panel will be done through: - -* Repository: https://github.com/solid/notifications-panel -* Discussions: https://gitter.im/solid/notifications-panel - -Information about the panel (for example, details about deliverables, issues, actions, status, and participants) will be available from the Notifications Panel repository. - -## Decision Policy - -As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an Editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, chat channel or panel repository) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. - -This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. - -## Licensing - -The panel will use the MIT license for all its deliverables. - -## Patent Policy - -This W3C Solid Community Group operates under the W3C Community Contributor License Agreement (CLA). - -## About this Charter - -This charter for the Notifications Panel has been created according to section 5.2 of the W3C Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. - -### Charter History - -The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3): - -| Charter Period | Start Date | End Date | Changes | -|-----------------|------------|------------|------------| -| Initial Charter | 2019-08-23 | 2021-09-12 | | diff --git a/repo-overview.md b/repo-overview.md deleted file mode 100644 index 23699b1..0000000 --- a/repo-overview.md +++ /dev/null @@ -1,31 +0,0 @@ -# Solid GitHub Repository Overview - -The [Solid GitHub organisation](https://github.com/solid/) contains several repositories. This document aims to provide an overview of the aim of each of the repositories and who is actively maintaining each repository. - -If you have more information [submit an issue](https://github.com/solid/process/issues) and a Solid Administrator will make a decision on how to incorporate the issue into this file. - -The following describes the governance, administration, and communication via the website: - -| Activity | Associated Repositories | Individuals Currently Active | -| ------------- | ------------- | ------------- | -| Administration | [owner on Solid members](https://github.com/orgs/solid/people) | Solid Director, Solid Manager, Administrators | -| Process | [Process](https://github.com/solid/process) | Solid Director, Solid Manager | -| solidproject.org | [solidproject.org](https://github.com/solid/solidproject.org), [solid github io](https://github.com/solid/solid.github.io) | Creators | -| Communication | [Communication](https://github.com/solid/communication) | Solid Director, Solid Manager | -| Roadmap | [Roadmap](https://github.com/solid/roadmap) | Solid Director, Solid Manager | - -These are the key [respositories associated to the specification development](https://github.com/search?q=topic%3Aspecification+org%3Asolid&type=Repositories) which are tagged 'specification' and are managed by the [Editors](https://github.com/orgs/solid/teams/editors) with input from the [Panellists](https://github.com/orgs/solid/teams/panels) - -| Activity | Associated Repositories | Individuals Currently Active | -| ------------- | ------------- | ------------- | -| Latest Version of the Specification | [Specification](https://github.com/solid/specification) | Editors | -| Specification Authoring | [authorization panel](https://github.com/solid/authorization-and-access-control-panel/issues/), [authentication panel](https://github.com/solid/authentication-panel), [interoperability panel](https://github.com/solid/interoperability-panel), | [Panellists](https://github.com/solid/process/blob/master/panels.md) | -| Test Suite Development | [Test Suite](https://github.com/solid/test-suite) | Editors | - -## Running Code - -There are several implementations of Solid in the Solid GitHub that can be found in [repositories tagged 'running-code'](https://github.com/search?q=topic%3Arunning-code+org%3Asolid&type=Repositories). IMEC and more specifically, [these team members](https://github.com/orgs/solid/teams/imec/members) are responsible for the [repositories listed here](https://github.com/orgs/solid/teams/imec/repositories). [These team members](https://github.com/orgs/solid/teams/other/members) are responsible for [these repositories](https://github.com/orgs/solid/teams/other/repositories). - -## Archived - -There are over thirty [archived repositories](https://github.com/solid?q=&type=archived&language=) with information that is now covered by solidproject.org or a reference to currently inactive panels. diff --git a/test-suite-panel-charter.md b/test-suite-panel-charter.md deleted file mode 100644 index 8b2a1f8..0000000 --- a/test-suite-panel-charter.md +++ /dev/null @@ -1,144 +0,0 @@ -# Test Suite Panel Charter - -The mission of the Test Suite Panel as part of the W3C Solid Community Group (CG) is to give authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards. - -* Start date: 2022-07-01 -* End date: 2025-06-30 -* Charter extension: The charter extension history is documented in "About this charter". -* Confidentiality: Proceedings are public -* Chair: [Sarven Capadisli](https://csarven.ca/#i) -* Team Contact: Solid Editors -* Usual Meeting Schedule: Teleconferences: Occur on a need to basis. The chair may call for topic-specific calls when needed and may change working mode as work progresses. - -## Goals - -The Test Suite Panel will operate with a mutual understanding between contributors to technical reports, test suite software maintainers, and software implementers by following a cooperation process for the advancement of the Solid platform. - -Writing tests in a way that allows implementations to conform to the requirements of a technical report gives Solid projects confidence that their software is compatible with other implementations. This in turn gives authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards. Implementation and interoperability experience can be verified by reporting on implementations passing open test suites. - -The panel will develop open source conformance testing software, author and review tests, release implementation reports, and provide feedback to technical report development. - -The work will be driven and refined by: representative tests for technical reports; quality control and assessment of test suite software; tests; and reporting. - -The panel will collaborate with other Solid panels and may take on or pass on challenges. - -The panel will contribute to the development of technical reports and releasing implementation reports as necessary, which may require re-chartering, e.g., to provide tests for new technical reports in the future. - -## Scope - -The panel within the framework of the W3C Solid CG and the Solid Project will complement the development of technical reports and support the communication of implementation reports. Features that are not implemented due to time constraints can be put into a non-normative "roadmap" document for future work. The scope will include: - -* Human- and machine-readable units of information at any level of granularity are available from technical reports, test reviews and reports, test suite design, test environment and setup, individual tests, and software implementations. -* Evaluation tools (software programs or online services) that help determine implementation conformance. -* Vocabularies for technical reports, test suite design, tests, and test reports. -* Documentation detailing setting up a test environment, authoring and running tests, reviewing tests, and publishing reports. -* Guidelines for improving conformance and variations among conforming implementations. -* Communicating the level of adoption of technical reports. - -Other components necessary for building conformance test software, authoring and reviewing of tests, and communicating implementation reports are in scope but will not lead to a deliverable without re-chartering, and should be discussed in the Test Suite Panel. - -### Success Criteria - -Test reports and summaries including required human- and machine-readable information (regardless of the mechanisms used to produce the documents). - -Publication of approved test reports. - -All deliverables should detail all known security and privacy implications for testers and implementers where applicable. - -There should be testing plans for each technical report, starting from the earliest drafts. - -To promote interoperability, new tests or modifications to existing tests should be available when there are changes to technical reports, or must include the rationale for why test updates are not required for the proposed update. - -## Deliverables - -### Normative Deliverables - -The panel will deliver the following to fulfill its goals, subject to discussion in the Solid CG: - -* Test conformance software. -* Tests, test reviews, test reports. -* Processes to author, review, and publish tests and reports. - -The Test Suite Panel will share its findings towards improving technical reports and implementations. - -### Other Deliverables - -The panel may deliver the following: - -* Best Practices and Guidelines to support test authors when designing tests. -* Guidance for implementation conformance. -* Document and inform about the level of adoption of technical reports. - -### Milestones - -The production of the deliverables depends upon the resources available, and will change as new technical reports are published and implementation experience is reported to the group. The most up-to-date timeline is available from the panel repository. - -Note: The Test Suite Panel as part of the W3C Solid CG does not publish technical reports under the W3C Recommendation track. Thus, any classification pertaining maturity level of potential technical reports are intended to be roughly equivalent to section 6.2.1 of the W3C Process. - -## Coordination - -Technical coordination with the following Groups may be required: - -### W3C Groups - -* [Evaluation and Repair Tools Working Group](https://www.w3.org/WAI/ER/) -* [Accessibility Guidelines Working Group](https://www.w3.org/WAI/GL/) -* [Spec Editors Community Group](https://www.w3.org/community/speced-cg/) - -Furthermore, the panel expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them: - -* [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications) -* [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/) - -### External Groups - -The panel may correspond with the [web-platform-tests Project](https://github.com/web-platform-tests/wpt). - -## Participation - -Membership in the W3C Solid CG is required to participate in the Test Suite Panel. All work and communication within the Solid CG is covered by the [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md) as well as the [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). - -To be successful, the Test Suite Panel is expected to have 5 or more active participants for its duration and to have the participation of contributors to technical reports, test suite developers, software implementers, test authors, and reviewers. The Chair, test suite developers, and contributors to technical reports are expected to collectively contribute one day per week towards the Panel. The Chair may call occasional meetings consistent with the W3C Process requirements for meetings. There is no minimum requirement for other Participants. - -The Test Suite Panel will also allocate the necessary resources for building test suites for each technical report. - -The group encourages questions and comments on its project repository, as described in Communication. - -## Communication - -Most Test Suite Panel Teleconferences will be conducted on an as-needed basis. - -Most of the technical work of the panel will be done through: - -* Repository: https://github.com/solid/test-suite-panel -* Discussions: https://gitter.im/solid/test-suite - -Individual work items are expected to use other repositories. - -Information about the panel (for example, details about deliverables, issues, actions, status, and participants) will be available from the Test Suite Panel repository. - -## Decision Policy - -As explained in the W3C Process Document (section 5), this group will seek to make decisions when there is consensus and with due process. The expectation is that typically, an Editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required. However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs should put a question out for voting within the group (allowing for remote asynchronous participation -- using, for example, chat channel or panel repository) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available. - -This charter is written in accordance with Section 5.2.3, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires. - -## Licensing - -The panel will use the MIT license for all its deliverables. - -## Patent Policy - -This W3C Solid Community Group operates under the W3C Community Contributor License Agreement (CLA). - -## About this Charter - -This charter for the Test Suite Panel has been created according to section 5.2 of the W3C Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence. - -### Charter History - -The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3): - -| Charter Period | Start Date | End Date | Changes | -|-----------------|------------|------------|------------| -| Initial Charter | 2022-05-09 | 2022-06-14 | |