Incorrect use of preprocessor tags to differentiate between datasets and services

[archaeogeek]

As per https://github.com/agiorguk/gemini/pull/134

I've realised that the preprocessor approach isn't the right one for differentiating between the datasets and services. The fix is actually a more efficient way of doing things. We can use the tagged regions approach: https://docs.asciidoctor.org/asciidoc/latest/directives/include-tagged-regions/. This requires the following changes:

• [ ] Change all ifdef::variant-dataset[]/endif::[] references to # tag::dataset[]/# end::dataset[] in all the include files
• [ ] Change all ifdef::variant-service[]/endif::[]references to # tag::service[]/# end::service[] in all the include files
• [ ] In 1062-gemini-datasets-and-data-series add a negative reference to the service tag in each include directive (this means it includes all regions EXCEPT the region tagged with service)
• [ ] In 1063-gemini-services add a negative reference to the dataset tag in each include directive (this means it includes all regions EXCEPT the region tagged with dataset)
• [ ] Remove the double processing in the live github action so that it no longer processes everything twice- once for datasets and once for services
• [ ] Remove the -a variant-datasetparameter from the live github action
• [ ] Remove the double processing in the dev github action so that it no longer processes everything twice- once for datasets and once for services
• [ ] Remove the -a variant-dataset parameter from the dev github action

[archaeogeek]

@PeterParslow could you do a sanity check of https://archaeogeek.github.io/gemini-dev/1062-gemini-datasets-and-data-series.html and https://archaeogeek.github.io/gemini-dev/1063-gemini-services.html (you could focus on keywords as being a good example of where the dataset and services guidance is different). If it looks OK I'll move it over to the agi repository

[PeterParslow]

I've compared the two HTML files in your repository for a handful of elements - it looks good. Well done for spotting this "better way" which also fixes some of the other "sub issues" I'd been having trying to fix issues.

I think it's good to go to DEV. May be good to go to LIVE - but you'd need to carefully manage which version of which ADOC file to set live.....

Well done, Jo. Again!

[archaeogeek]

Moved to "to implement"