New Work Item: Application Capability
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
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)
- 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.
- 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.
- 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.
- 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.
- 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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di solid/specification
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
solid/specification#804 · 9 commenti · 2 reazioni ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
solid/specification#799 · 1 reazione ·
-
topic: resource access
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
solid/specification#797 · 4 commenti · 2 reazioni ·
-
End-to-End Encryption (E2EE)Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
solid/specification#788 · 4 commenti · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 38/100
solid/specification#787 · 19 commenti · 10 reazioni ·
Tutte le issue di solid/specification
Issue simili
-
sync-en
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 2 giorni
-
external
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
langchain-ai/docs#6255 ·
I maintainer di solito rispondono entro 1 giorno
-
detectors enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
SM260845/readme-gen#1 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
angular/angularfire#3774 ·
I maintainer di solito rispondono entro 2 giorni
-
Lychee link check failedApertagood first issue help wanted opensource september
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100