Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

New Work Item: Application Capability

Aperta
#806 11 commenti 4 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
documentation

Direzione di ricerca

Inizia con le indicazioni per i nuovi elementi di lavoro in CONTRIBUTING.md, quindi leggi la proposta collegata di Application Capability e i verbali della riunione del 2026-07-15, incluso PR #805. Il lavoro è considerato completato quando l’ambito della proposta è definito, il feedback della community è stato affrontato e sono stati concordati il suo contesto e i prossimi passi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

new-work-item

As per https://github.com/w3c-cg/solid/blob/main/CONTRIBUTING.md#new-work-item-proposal

and following the action of initial presentation/discussion in 2026-07-15 Solid CG meeting (minutes under review).

Application Capability: https://dokieli.github.io/application-capability/

Editors/Authors: Sarven (@csarven) and Virginia (@VirginiaBalseiro)


  1. Explain what you are trying to do, using no jargon or acronyms.

We want to communicate the capabilities and requirements of an application so that it can be used by other applications or servers to make more informed decisions.

  1. How is it done today, and what are the limits of the current practice?

To the best of our knowledge, information with regards to an application's capabilities and requirements is scattered across mechanisms that each cover a slice, such as web app manifests, browser permissions, and security policies. None of them lets a server or another application (e.g., an Web OS, launcher, catalogue, resource manager, etc.) discover what an application supports or needs. The result is hardcoded application lists, manual catalogue updates, and overly permissive policies.

  1. What is new in your approach, and why do you think it will be successful?

An application publishes one discoverable, structured description of its actions, supported resource types, how it can be invoked, and what permissions it needs, e.g., from a web user agent or server. It reuses existing vocabularies and notification mechanisms as much as possible.

There is a need in the community, with implementers already tackling parts of the problem outlined in Application Capability, and there is some implementation experience. This spec tries to bring prior discussions and work together (see CG minutes for background references) into something coherent that we can use.

  1. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: Africa, the Americas, APAC, Europe, Middle East, Antarctica.)

The authors/editors are based in Europe and have some familiarity with the web =) For more details, see their WebID, CV, etc.

  1. What actions are you taking to make this work item accessible to a non-technical audience?

We have tried to explain the problem space and related work as clearly as possible. Some of the use cases in the specification are written from the point of view of a user (with different abilities or roles).

We are available to answer questions, revise, and join meetings that have better open lines or access to a non-technical audience.


We also want to note that this work is not strictly limited to the Solid community. We have considered sharing it more widely with other groups and initiatives in W3C, e.g., Web Application(s) (Security) WGs, WICG, and elsewhere (see "related efforts" in the spec) that may be equally or more appropriate.

We want to make sure this is compatible with Solid and related efforts, and to incubate and gather experience here, while remaining open to migrating the work to another venue as we better understand where it can best mature and be useful in different context.

Lingua principale
HTML
Stelle
563
Fork
110
Merge medio
5g 7m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/specification

Tutte le issue di solid/specification

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.