[DOC] configuration.rst

[kaystrobach]

trafficstars

• fix broken xsd uri
• change not allowed html-theme to theme

[kaystrobach]

Yep, did not work do fetch the xsd, as we do not use the vendor folder in that project. I would prefer to have the xsd centrally stored. This way you can validate it even without the dependencies installed.

[linawolf]

I think we had that discussion before and descided for some reason to use relative URLs, can you remember why, @jaapio ?

[garvinhicking]

IIRC the main reason was that we figured the XSD would be changed around and we didn't have a URI where the XSD would be published already (and would maybe need release versioning).

For a 1.0 release we should really provide a stable URI somewhere. Maybe if we bundle it within the documentation of render-guides and use that "main" version as a stable link?!

[kaystrobach]

The uri should contain a version number.

[garvinhicking]

What's the best practice here if the XSD is in another repository, where the release versions don't reflect changes in the xsd itself (i.e. version 2.3.0 of the package uses the same xsd as in version 0.3.0 - so we have new package versions without the xsd changing. And if the xsd would get a new attribute in version 3.0 of the package that we don't use though, we would need to remember changing all xsd URIs in our docs?

Probably we need to add the xsd to our own domain because of this (=copy it into our own render-guidey repo)?

[kaystrobach]

Imho the xsd is a technical description. It should only have mayors as versions. Maybe exceptions for lower versions until 1.0

Maybe you also have „latest“ which can be used in the docs. 🤷‍♂️