search

VNG-Realisatie / VNG-R-Respec-Organization-configurations

VNG-R global configurations repository voor Respec
https://vng-realisatie.github.io/VNG-R-Respec-Organization-configurations/
Other
0 stars 0 forks source link

Uit welke componenten moeten de urls in de header bestaan? #17

Open melsk-r opened 7 months ago

melsk-r commented 7 months ago

De inhoud van de velden 'Deze versie:', 'Laatst gepubliceerde versie:' en 'Vorige versie:' in de documentatie wordt gedefinieerd in de globale configuratie properties:

Op dit moment zijn deze resp. als volgt gedefinieerd:

Waarbij 'nl_organisationPublishURL' en 'pubDomain' eveneens globaal zijn gedefinieerd resp. met de waarde https://vng-realisatie.github.io/publicatie en cim.

'shortname' wordt altijd lokaal gedefinieerd en kan bijv. de waarde ori hebben zodat de uiteindelijke waarde voor 'thisVersion' gelijk wordt aan
https://vng-realisatie.github.io/publicatie/cim/ori/2.0.0. Na 'nl_organisationPublishURL' wordt automatisch al een '/' gegenereerd reden waarom deze daar in deze properties niet wordt gedefinieerd.

Er is op dit moment voor gekozen de 3 properties (latestVersion, thisVersion en prevVersion) op te bouwen zonder een specificatiestatus en een publicatiedatum. Deze zouden er ook nog aan toegevoegd kunnen worden of juist een nu aanwezige property kunnen vervangen. Ook kunnen er een of meer, nog te creëren, properties aan toegevoegd worden waarbij dan bekeken moet worden of die globaal of lokaal gedefinieerd moeten worden. Zo zou je er bijv. voor kunnen kiezen de configuratie property 'pubDomain' lokaal te definiëren en deze naast cim aan te vullen met /zd (Zaken en Documenten), /bk (Basis en Kerngegevens), /dv (Dienstverlening), /rd (Ruimtelijk domein), /sd (Sociaal domein) of /bv (Bedrijfsvoering).

Let op! Hou in de gaten dat dat alles zou betekenen dat de in de 'publicatie' repository geïmplementeerde structuur moet worden gewijzigd en mogelijk complexer wordt.

Vandaar de volgende vragen:

Ik stel voor de instelling voor de 3 genoemde properties de gebruiken. Maak dus geen gebruik van properties voor het specificeren van de document status en/of de versiedatum. Daarnaast stel ik voor om de property 'pubdomain' een globale waarde te geven en toe te staan dat deze lokaal overruled kan worden. De waardes die we daarvoor toestaan moeten we wel met elkaar afstemmen. Afwijkende waardes moeten we niet toestaan aangezien we daarmee het gevaar lopen dat de structuur van de publicatie repository uit de hand loopt. Nieuwe gewenste waardes moeten als m.b.v. een issue als verzoek in de onderliggende repository worden ingebracht.

hdksi commented 5 months ago

Even een check: wat als straks (wat me heel voorstelbaar lijkt) dat we ook de gedragsspecificaties bij API-standaarden in Respec willen publiceren? Zijn we ons er dan van bewust dat die vanuit de publicatie-repo worden geserveerd? Wat mij betreft is dat geen issue, maar wel iets om bij stil te staan.

Dit betekent volgens mij ook dat "pubDomain" overruled moet kunnen worden. Niet alle gepubliceerde artefacten hoeven immers een cim te zijn.

melsk-r commented 5 months ago

Even een check: wat als straks (wat me heel voorstelbaar lijkt) dat we ook de gedragsspecificaties bij API-standaarden in Respec willen publiceren? Zijn we ons er dan van bewust dat die vanuit de publicatie-repo worden geserveerd? Wat mij betreft is dat geen issue, maar wel iets om bij stil te staan.

@hdksi Mijn uitgangspunt is dat we alle Respec documenten van VNG-R vanuit de publicatie repo publiceren. Ik zie geen reden om verschillende publicatie repositories te creëren.

Dit betekent volgens mij ook dat "pubDomain" overruled moet kunnen worden. Niet alle gepubliceerde artefacten hoeven immers een cim te zijn.

Zie daarom mijn voorstel in dit issue om ook andere waarden voor 'pubDomain' toe te staan. Dat moet wel een vaste lijst zijn. Ik heb het zojuist nog even gecheckt maar 'pubDomain' kan lokaal overruled worden dus wat dat betreft zit niets ons in de weg.

melsk-r commented 4 months ago

@hdksi Misschien goed om dit en hiermee verband houdende issues nog even samen te bespreken. N.m.m. moeten we dit niet te vrij laten want dan wordt de structuur in de 'publicatie' repo een chaos.

melsk-r commented 4 months ago

Zie ook issues #15, #16 en #21.

markbacker commented 4 months ago

Is er in deze URL opbouw ook een URL waarnaar je kunt verwijzen onafhankelijk van de versie? Bijvoorbeeld https://vng-realisatie.github.io/publicatie/cim/ori of https://vng-realisatie.github.io/publicatie/cim/ori/currentVersion.

melsk-r commented 3 months ago

Ja, in jouw voorbeeld is dat de eerste (https://vng-realisatie.github.io/publicatie/cim/ori). Daar kan steeds de laatst gepubliceerde versie gevonden worden. Let op dat is dus wat anders dan de laatste werkversie.