Profiles
incubatingStatus 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 .
Goal: define interoperability when not everyone implements everything, and make extensions safe across tools.
1. Normatives to evaluate
Profiles: named capability sets (e.g.,
blueprint-core,blueprint-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 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"?
4. Must-align with
[UJG Core] extension mechanics
[UJG Blueprint] explicit vs outgoing transitions
[UJG Runtime] event tracing
[UJG Mapping] stratgies to handle cross-journey jumps
[UJG Metrics] aggragation depth
References
Informative References
- [UJG Blueprint]
- UJG Blueprint. /ed/blueprint
- [UJG Core]
- UJG Core. /ed/core
- [UJG Mapping]
- UJG Mapping. /ed/mapping
- [UJG Metrics]
- UJG Metrics. /ed/metrics
- [UJG Runtime]
- UJG Runtime. /ed/runtime