Skip to content

Variability in Solid specs #138

@csarven

Description

@csarven

Creating this issue to systematically approach variability in Solid spec(s): https://www.w3.org/TR/spec-variability/ .

Below are some rough notes I took awhile ago. It can help us to better organise the specs and actually document variances. [This goes far beyond spec orthogonality.]

Classes of products

  • Responding agent (e.g., server) of API (consumer and producer)
  • Specification (guidelines)

Specification category

  • Set of guidelines
  • Content/data
  • Protocol

Subdivisions by profiles

Nothing on the table?

Subdivisions by modules

Solid ecosystem doc consists of functional groups - can be implemented independently / clear divisions

Subdivision by levels

May be possible with minimal set and build up (progressively enhanced?) eg. WebID -> WebID+OIDC -> WebID+OIDC+ACL

Discretionary items

  • Discretionary choices -- aim to avoid or minimise cases
  • Optional features -- but well-defined if supported; specify affects -- significant? can/should this be a module?
    ** eg. Servers MAY support Slug. If supported, apply shared slash semantics on slugtext
  • Implementation dependent values (or features) -- eg. ldp:constrainedBy makes this possible

Deprecated features

Mention anything? eg. globbing? trustedApp?

Extensibility

Which components; profile/module/level?

Umbrella specifications

The Solid Ecosystem is an umbrella specification due to following reasons:

  • the technology is too big to present in one document -- true
  • the technology evolves over time -- true
  • the technology is easier to understand or organize as multiple documents -- most likely
  • the technology consists of several modules or subdivisions that revolve around a single information model or framework -- possibly

Key components:

  • Protocol
  • Identity
  • Authentication
  • Authorization
  • Data
  • Clients and Applications
  • Considerations (security, privacy, accessibility, internationalization)

Documents supporting the specifications:

  • Primer
  • Use Cases and Requirements
  • Best Practices and Guidelines

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions