Better distinction between normative and informative text

[pietercolpaert]

In the specification there’s an overview section, for which it is unclear what is normative and what is informative. I would propose to keep the overview as succinct as possible, and include normative text in the sections below.

There’s a conversation also on Matrix: https://matrix.to/#/!HCYaBzWmkpZlPcCyAL:chat.semantic.works/$N94r15FWdx9ORJFy9PlZCWZhPfF4LTVG5C7BH3a9Bow?via=chat.semantic.works&via=matrix.org&via=gitter.im

There it is suggested to make the requirements explicit and maybe take an example to the Solid specification tests: https://github.com/solid-contrib/specification-tests?tab=readme-ov-file#annotations

It might also be interesting to have a section on classes of products: https://solidproject.org/TR/notifications-protocol#classes-of-products for:

1. An LDES Server (see primer)
2. An LDES client
3. An LDES consumer pipeline with processors

[xdxxxdx]

The Solid specification tests are implemented using the KarateDSL test automation framework. They are quite similar to the end-to-end tests developed by VSDS: https://github.com/Informatievlaanderen/VSDS-LDES-E2E-testing.

To have such testing, we indeed need a library that includes both server and client components (in the automation framework), as well as a clearly scoped normative specification—or a conformance specification that defines how to interpret restrictions.

[pietercolpaert]

In the 4th work session today, we’ve established that we’ll restructure the spec a bit even more:

We’ll add an extra layer in which https://w3id.org/ldes/specification becomes the landing page that then refers to:

1. The vocabulary
2. The client algorithms
3. Application profiles with SHACL shapes for root nodes and subsequent nodes
4. The server primer

The overview itself must explain why you should read further. Good examples can be drawn from @rorlic’s step by step guide: https://github.com/rorlic/ldes-docs/blob/main/step-by-step/A-why-do-we-need-ldes.md