This site is under heavy development. Content and features may change frequently.
UJG / Editor's Draft /
W3C Community Group Draft Report

Profiles

incubating

Status of this Document

This report was published by the User Journal Graph Community Group . It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups .

Last Update
2026-01-28
Editors
  • Seva Dolgopolov
Group
User Journal Graph Community Group
Repository
View Source
License
W3C-Software-and-Document

Goal: define interoperability when not everyone implements everything, and make extensions safe across tools.

The Supported Extensions published in the Editor's Draft define the official optional extension family. Profiles are the future place to describe how implementations declare support for those extensions, how extensions are bundled into named capability sets, and how consumers degrade gracefully when optional capabilities are absent. This draft does not yet standardize the declaration format for those claims.

1. Normatives to evaluate

  • Profiles: named capability sets (e.g., graph-core, graph-composition, runtime-basic, runtime-mapped).

  • Profile declaration: how a producer/emitter/consumer declares supported profiles (document-level field vs out-of-band).

  • Extension interoperability rules:

    • what "namespaced" means (URI-like vs compact prefix registry),

    • collision handling,

    • versioning expectations for extension vocabularies,

    • pass-through requirements for stores/proxies.

  • Profile conformance rules:

    • what it means to "conform to profile X",

    • required keys/behaviors per profile,

    • how a consumer should degrade gracefully when profile data is missing.

2. Informatives to evaluate

  • Recommended starter profile set for TR v1.

  • Patterns for supported extensions and vendor modules (e.g., UI presentation, experimentation, privacy).

  • Examples: same Journey expressed with/without optional profile features.

3. Decisions to make

  • Do profiles live inside the JSON payload (e.g., profiles: ["..."]) or outside (HTTP header, metadata)?

  • Do you want a formal prefix registry for compact namespaces, or just "SHOULD be URI-like"?

  • How should implementations declare support for the Supported Extensions published in the Editor's Draft?

  • How should profiles bundle supported extensions into named capability sets?

4. Must-align with