Variability in Solid specs

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