Some basic questions about layers for Protected Sites theme - naming, type in WMS service

[Ana-SGA]

Hello all, help needed. We are testing this service for Protected Sites theme:

https://geoportal.kulturnadobra.hr/servisi/grafika/ProtectedSites/wms?service=WMS&request=GetCapabilities

through INSPIRE Validator, it fails for harmonized the layer name:

https://inspire.ec.europa.eu/validator/v2/TestRuns/EID0844625f-ecf9-473e-8b98-64db95ae9539.html

According to the INSPIRE layer register, there is only one layer name available for Protected Sites theme - PS.ProtectedSite. In Data Specification, there aren't any layer names specified (or?), only layer types which the contractor used as layer names. Are they equal? And can there be multiple layers for this theme and which harmonized layer names should we use?

Also, we are trying to understand Aggregated and Component layers, can anyone explain in a simple way (we are not programmers) or show an example of implementation?

Data Specification: https://inspire.ec.europa.eu/id/document/tg/ps

Thanks to all!

[MarcoMinghini]

Dear @Ana-SGA, thanks for opening this issue. We have just migrated the old helpdesk into this new one, so I have transferred your issue that will now be visible to the whole team.

[Ana-SGA]

Hello Marco, thank you for notifying me. Hope someone will see this soon so we can solve this problem.

[iuriemaxim]

@Ana-SGA I tested https://geoportal.kulturnadobra.hr/servisi/grafika/ProtectedSites/wms?service=WMS&request=GetCapabilities
against WMS Conformance Class and the service is passing on staging environment (http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/), as it can be seen at
http://staging-inspire-validator.eu-west-1.elasticbeanstalk.com/etf-webapp/v2/TestRuns/EID8384830a-cd2e-47e2-b029-c249db58319d.html

However the test is not passing on the production environment (https://inspire.ec.europa.eu/validator) and it provides the following error:

https://inspire.ec.europa.eu/validator/v2/TestRuns/EID7baee4df-9214-4b6d-85c6-1cabfd5a41e5.html)

The error is not in relation with PS.ProtectedSite, but with PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape that most probably are not included yet in the production environment and possibly that they are included in the staging environment.

There is a bug raised here about the missing layer names, so the problem is known:
#382

I added the PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape to the issue 382, as probably they are already added in staging environment. If they are not added in the staging environment, than there is another issue that was raised most probabbly due to the following fix that is not correct according to me:
#255

Thats why, @carlospzurita please confirm that this is the issue.

[Ana-SGA]

Hello @iuriemaxim - thanks for helping and testing. Yes, we know that PS.ProtectedSite is a harmonized layer name as it is specified in Data Specification for PS and in INSPIRE layer register and INSPIRE Validator doesn't fail for it. PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape are names that the contractor used, but in Data Specification on PS they are layer types and don't exist on INSPIRE layer register as harmonized layer names.
I really appreciate your input, help and explanation and hope that by adding PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape on INSPIRE Validator production environment the problem will be solved.

[iuriemaxim]

I really appreciate your input, help and explanation and hope that by adding PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape on INSPIRE Validator production environment the problem will be solved.

@Ana-SGA Hope so. This is something that @carlospzurita can confirm or infirm as it is possible to be also other interdependencies as I already mentioned #255 and potential other tests that were relaxed and already implemented on staging environment.

[carlospzurita]

Dear @Ana-SGA

Sorry for the delay on the response, with the movement of helpdesk we lost track of this one.

The reason this test is failing is because indeed the layer names ProtectedSitesCultural, ProtectedSitesArchaeological, ProtectedSitesLandscape are not available in the INSPIRE registry, as you can check here

The reason the test is passing in staging, as @iuriemaxim is because, as way to address the discussion on #39, we made available there a change, setting the harmonization of layer names as manual test.

For now, the change is not official, and the test is going to remain as it is on the production instance, using only the layer names contained in the INSPIRE registry. We are marking this issue as user-to-fix

I hope that this response can summarize the situation.

[Ana-SGA]

Hello @carlospzurita thanks for explanation. But I don't understand - for Protected Sites there can be only one layer since there is only one harmonized layer name? Or?
Can someone look at my first question also - about Aggregated and Component layers?

[iuriemaxim]

@carlospzurita it is good that #39 (View Service WMS validator too strict: harmonized layer names should not be mandatory) is not implemented in the production environment as I stated that is incorrect to relax this test. However it should not be implemented in the staging environment as well, because as you see it creates confusion.

However it is not correct that you marked the issue with the tag "user to fix" because the user has nothing to fix. Is the INSPIRE Registry to be fixed, becuase the layer names that are triggering the error are actually present in the Technical Guideline as can be seen in the image below:

My understanding is that now due to all this migration that caused all the problems with the broken links, here should be addressed all the issues including those that are related to the Registry that is causing problems to the validator. So probably it should be marked with "Registry-to-fix".

[iuriemaxim]

Can someone look at my first question also - about Aggregated and Component layers?

The Technical Guideline for Protected sites is quite clear. Assuming you have 3 protected sites categories you are obliged to expose only the PS.ProtectedSite.Default.

"The Protected Sites theme is represented with a number of layers. By default, a layer containing the contents of the entire ProtectedSite spatial object type is to be provided. Additionally, view services may optionally provide layers reflecting:

• the site protection classification (ProtectedSite.siteProtectionClassification);
• the site designation (ProtectedSite.siteDesignation.designation) and
• the site designation scheme (ProtectedSite.siteDesignation.designationScheme)."

So there is a recomandation 38 to expose throug WMS more layers, in this case: one for each category (3 layers) and one more for all protected sites categories (so 4 layers in total).

This means that the WMS service that was created comply also with the recommandation 38 of the TG for Protected Sites.

This is to allow the users to see a map with either one category, two categories or all categories, by indicating which layers to be loaded. Therefore the GetCapabilities document is correct, as it is listing all the protected sites categories that can be visualised.

Is just that the registry is incomplete and as a consequence the validator triggers the error listing those layer names that are actually not present in the INSPIRE Registry even if they should be there.

The recomandation 38 is actually quite important to implement if the dataset is a national one. Supossing for example that the Natura 2000 sites are present in the database, it is well known that SPAs and SCIs (SACs) are overlaping, so if they are presented only alltogether (agregated) without presenting them separated, then the view is not suitable because the boundaries of the sites will intersect and will not be possible to understand nothing from that image that is composed only by black lines with the same width and poligons without fill. Even if there is no obligation, but just a recomandation the view service will not be usable, so the users will just spot that the service is usless and that they just spent time to discover the view.

For example, suposing that the dataset for which you are creating view services contains only Archaeological, Cultural and Landscape protected sites in the view service it should be exposed four layers:

1. PS.ProtectedSitesArchaeological
2. PS.ProtectedSitesCultural
3. PS.ProtectedSitesLandscape
4. PS.ProtectedSite

For each one, the view service should have at least one associated style (i.e. SLD - Style Layer Descriptor) that will be the default one, so there will be the following styles:

1. PS.ProtectedSitesArchaeological.Default
2. PS.ProtectedSitesCultural.Default
3. PS.ProtectedSitesLandscape.Default
4. PS.ProtectedSite.Default

The same SLD can be used as default for all the layers, but also it is possible to define a separate default SLD for each layer.

The Default style should be based on the portrayal rules set in the Technical Specification, i.e. black continuous line of a certain width for the outline with no fill.

It is possible to create other styles as needed, as for example to use a certain fill, hatched or solid with a different colour for each specific category. In this case the view service can have suplementary styles to the four default ones:
5) PS.ProtectedSitesArchaeological.HatchGreen1
6) PS.ProtectedSitesCultural.HatchRed1
7) PS.ProtectedSitesLandscape.HatchPink1
8) PS.ProtectedSite.CrossHatchGrey3
9) PS.ProtectedSitesArchaeological.SolidFillGreen
10) PS.ProtectedSitesCultural.SolidFillRed
11) PS.ProtectedSitesLandscape.SolidFillPink
12) PS.ProtectedSite.SolidFillGrey
and so on, as needed, but at leas the default ones are necessary.

This means that the data should be filtered based on the protected site category in order to see only that specific category and then to apply one or more simbolisations.

Hope it helps.

[iuriemaxim]

Hello @carlospzurita thanks for explanation. But I don't understand - for Protected Sites there can be only one layer since there is only one harmonized layer name? Or?

@carlospzurita All the other harmonsed layer names should be added in the INSPIRE Registry even if the user is not obliged to use them. But if the data provider is using any other layer name for representing a certain category of protected area, then it is obliged to use the harmonised layer name according to Art. 14(3) of the IR. That's why these layer names should be present in the INSPIRE Registry.

This is the case of @Ana-SGA which decided to create a view service that is compliant also with the recommandation 38 of the TG. Ana-SGA is now confused, as she understands that the view service should not contain the "Component layers", even if the TG recomannds users to include the "Component layers".

@carlospzurita remove the tag "User-to_fix" in order not to confuse the user, as the user is correct.

[Ana-SGA]

For each one, the view service should have at least one associated style (i.e. SLD - Style Layer Descriptor) that will be the default one, so there will be the following styles:

1. PS.ProtectedSitesArchaeological.Default

2. PS.ProtectedSitesCultural.Default

3. PS.ProtectedSitesLandscape.Default

4. PS.ProtectedSite.Default

The same SLD can be used as default for all the layers, but also it is possible to define a separate default SLD for each layer.

Hello @iuriemaxim - thanks a lot :) but again, if only one default style is defined in the Data Specification on PS PS.ProtectedSite.Default - won't the Validator return an error on others https://github.com/inspire-eu-validation/view-service/blob/review-ats-tg_3.11/iso-19128/at42-getcapabilities-layer-default-style.md? Or we can use the same default style for all layers as you wrote?

Hello @carlospzurita if the Data Specification on PS suggests multiple layers (but defines name for only one layer) - which INSPIRE harmonized layer names should we use for the rest of them?

[iuriemaxim]

@Ana-SGA

The validator provides an error not because of your service, but because the validator is based on the INSPIRE Registry which is not including all the layer names as it should do.

If you want to change your service just in order to pass, even if your service is correct, than it should be understood that the error triggered is due to the 3 component layers that are served by the WMS. The validator does not care that you are using the same style for all the layers (see in green in the image below). Do not make a confusion between a layer and a style. Different layers can have the same style and one layer can have multiple styles, not just one. So there is a one-to-many relationship between layer and style. Your WMS service has 4 layers and 1 style (the same style is asociated to all layers).

Regarding the question to carlospuritsa, you make a confusion betwen layers and styles. Indeed the TG defines only one style (Default) for only one layer (PS.ProtectedSite). But the TG defines names for multiple layers that you are calling them component layers.

PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural & PS.ProtectedSitesLandscape are such layer names that are defined in the TG and that are correctly mentioned in your GetCapabilities document of the WMS Service. Once again the error is in the validator, or more specific in the INSPIRE Registry from where the validator is taking the layer names.

What need to be fixed is the INSPIRE Registry, if those layer names are not included as @carlospzurita suggest.

[Ana-SGA]

Okay @iuriemaxim I think you misundersood me. The question was, based on what you wrote - if we use default styles as you suggested (change using the same one for all layers) - will the Validator return an error since those default styles are not defined in the Data Specification. It is obvious that the Validator doesn't return an error on styles for now. In my question to carlospzurita I didn't mention styles at all and separated it from the question about styles. The question still stands and it is still about the layer names.

@carlospzurita can you please take a look again: can those layer names be added to the Registry? If the Data Specification suggests using multiple layers, which harmonized layer names should we use for the rest of them?

[iuriemaxim]

Okay @iuriemaxim I think you misundersood me. The question was, based on what you wrote - if we use default styles as you suggested (change using the same one for all layers) - will the Validator return an error since those default styles are not defined in the Data Specification.

@Ana-SGA The validator should not provide any error if you are using the same style for all layers. There is no requirement for styles names in the TGs, except for ”PS.ProtectedSite.Default” but I think that is important to use the word ”Default” in order to indicate the default style for each layer, i.e: ”PS.ProtectedSitesArchaeological.Default”.

However you may use the ”PS.ProtectedSite.Default” style (style name) for the ”PS.ProtectedSitesArchaeological” layer as it does not contradict any rule, but use of ”PS.ProtectedSitesArchaeological.Default” style name would be more intuitive and would be even better to have a different symobilisation than the one used in the ”PS.ProtectedSite.Default” style.

On the other hand PS.ProtectedSitesArchaeological, PS.ProtectedSitesCultural, PS.ProtectedSitesLandscape, PS.ProtectedSitesNatura2000, PS.ProtectedSitesNatureConservation, PS.ProtectedSitesSpecialAreaOfConservation and many others, are harmonised layer names, so it is ok that they were used in your WMS. If you used for example PS.ArcheologicalSites, than indeed, this was not ok. But the names of the layers that were used in your WMS are the harmonised ones.

The TG for Protected Sites is providing the SLD only for one style, because it may be the case that some data providers would make view services only for ”Aggregated” protected sites and not for each classification/category as they would not implement the recomandation 38.

[iuriemaxim]

This is the list of harmonised layer names for the Protected Sites Data Theme that are missing in the INSPIRE Registry:

Harmonised layer names that need to be added in the INSPIRE registry for the Protected Sites Data Theme:

Based on https://inspire.ec.europa.eu/codelist/Natura2000DesignationValue:
PS.ProtectedSitesSpecialAreaOfConservation
PS.ProtectedSitesSpecialProtectionArea
PS.ProtectedSitesSiteOfCommunityImportance
PS.ProtectedSitesProposedSpecialProtectionArea
PS.ProtectedSitesProposedSiteOfCommunityImportance

Based on https://inspire.ec.europa.eu/codelist/IUCNDesignationValue:
PS.ProtectedSitesStrictNatureReserve
PS.ProtectedSitesHabitatSpeciesManagementArea
PS.ProtectedSitesManagedResourceProtectedArea
PS.ProtectedSitesNationalPark
PS.ProtectedSitesNaturalMonument
PS.ProtectedSitesProtectedLandscapeOrSeascape
PS.ProtectedSitesWildernessArea

Based on https://inspire.ec.europa.eu/codelist/DesignationSchemeValue:
PS.ProtectedSitesIUCN
PS.ProtectedSitesNatura2000
PS.ProtectedSitesRamsar
PS.ProtectedSitesNationalMonumentsRecord
PS.ProtectedSitesUNESCOManAndBiosphereProgramme
PS.ProtectedSitesUNESCOWorldHeritage
PS.ProtectedSitesEmeraldNetwork

Based on https://inspire.ec.europa.eu/enumeration/ProtectionClassificationValue:
PS.ProtectedSitesNatureConservation
PS.ProtectedSitesArcheaological
PS.ProtectedSitesCultural
PS.ProtectedSitesEcological
PS.ProtectedSitesLandscape
PS.ProtectedSitesEnvironment
PS.ProtectedSitesGeological

I added the issue INSPIRE-MIF/helpdesk-registry#5 for the INSPIRE Registry in case that the INSPIRE Validator is reading the layer names from the INSPIRE Registry. Otherwise these layer names should be added in the Validator in order not to triger fake errors in relation with view services made for Protected Sites data theme.

[Ana-SGA]

@carlospzurita can you please take a look again - can it be solved through adding harmonized layer names for the PS theme to the Registry? Or? Else, what names should we use for multiple layers?

[carlospzurita]

Dear @Ana-SGA

We are discussing this issue internally and checking what should be added on the INSPIRE registry. We will get back to you with a response as soon as we can.

[iuriemaxim]

@carlospzurita would be good first to remove the tag ”user-to-fix” as it is confusing and incorrect.

[fabiovin]

Dear @Ana-SGA,
you can see my comment on a similar issue here #382 (comment).

At the moment, we don't foresee adding the additional/recommended layers defined by TGs in the INSPIRE Registry.

You can still use the layers defined by TG but you need to provide also the default one "PS.ProtectedSite" to be compliant with the IR.

[Ana-SGA]

Dear @fabiovin,

thanks for the information. We have a default "PS.ProtectedSite" layer and I've tested our WMS service through the staging instance - it passed with manual checks required. Do you know when will it be on officially on the INSPIRE Validator? So, from now on - besides harmonized layer names given in the INSPIRE Registry - any other names are good?

[fabiovin]

Dear @Ana-SGA,
it should be included in the next release, see the release planning here.

Yes, the validator will not raise an error for the additional layers, including those recommended by TG.

We are discussing internally if and how to insert also the additional layers defined by the TGs in the Registry.

[Ana-SGA]

Dear @fabiovin,

I guess that if and when you insert additional layers to the Registry, it won't affect the tests that have already passed for the WMS services (existing layer names won't have to be changed)?

[fabiovin]

Dear @Ana-SGA,

no, it will not affect the validation results.

The only difference could be that you will receive a fully 'green' result if your WMS includes only mandatory (by IR) and recommended (by TG) layers.

[Ana-SGA]

Dear @fabiovin,

thanks for all the information.

[iuriemaxim]

Dear @fabiovin thank you for information. I have also some comments and questions if possible for a feedback:

I think that if fulfilling a recomandation the validator should not provide an error as it is doing now. I think that this should be quite a general rule for the validator.

I supose that the fix should not allow users to provide any un-harmonised layer name. Will it be like this?

By next release do you mean the one from next week (15.03.2021) ? The issue is actually in relation with the INSPIRE Registry, not with the INSPIRE Validator. This means that by next week the harmonised layers will be present in the INSPIRE Registry?

Or the validator is not reading the harmonised layers from the INSPIRE Registry. I did not looked in the code to see if the hrarmonised layers are hardcoded or are retrieved from the INSPIRE Registry. Can you clarify a little bit?

From the perspective of an INSPIRE consumer and data processor, I want to know if the validator can be used in order to check if the INSPIRE View Services exposed in the INSPIRE Geoportal have harmonised layers that complies with the view TG or not, so I should know which services can be used for aggregating views at the EU level and which cant. Otherwise a paralel validator will need to be developed and maintained by the INSPIRE community or by the interested parties to fit for purpose of validating against the INSPIRE TG and not based on relaxed tests.

[iuriemaxim]

Probably relevant to this issue is the incident that I raised for the INSPIRE Registry INSPIRE-MIF/helpdesk-registry#5 (comment) answered and closed today by @hernlor

<<Dear @iuriemaxim , thank you for your request.

First of all, apologies on behalf of the INSPIRE Registry team for the delay in reacting.

We are in transition from the former issue tracker and we were setting up the governance workflow (not completely finished yet).

Indeed, there are layers appearing in the technical guidelines that do not appear in the registry. The reason is explained in the content summary of the layer register "The INSPIRE layer register contains all the harmonised layer, as defined in the COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services together with its amendments."

We are in touch with the INSPIRE Validator colleagues to overcome these issues. However, if you deem that change to be a priority, please get in touch with your respective submitting organisation.

Please remember that requests impacting the content of the INSPIRE registry are reserved exclusively to the appointed submitting organisations. Contact details of the appointed submitting organisations are available here: https://github.com/INSPIRE-MIF/helpdesk-registry/blob/main/submitting-organisations-list.md

Kind regards,
INSPIRE Registry team>>

Most probably in this case the Validator should not take into consideration only the values that are found in the INSPIRE Registry, but those that are listed in the TGs as well in order not to provide errors when data providers are implementing recomandations of the TG.

@carlospzurita Please consider to re-open the incident.

[Ana-SGA]

Dear @fabiovin, @carlospzurita, @hernlor

as I can see on the INSPIRE Validator, the relaxed test has not been implemented yet and our service still fails the test even though the contractor used one layer with name as defined in Commission Regulation 1089/2010 and additional layers as defined in Data Specification on PS - Guidelines (although now there are additional errors for schema validation and wrong layer names are not specified). On staging instance the test passes in orange (manual checks required). Shouldn’t it pass in green since the correct layer names were used? For this reason I think that recommended layer names should be added to the INSPIRE Validator/Registry – since they are recommended for all Member States how can using them cause an error?

[iuriemaxim]

@Ana-SGA The test should not be relaxed in the Validator, but only should be correctly implemented. Currently it is wrongly implemented as it triggers errors if the users are implementing recommandations of the TGs.

In order to be added the values to the INSPIRE Registry, I raised the incident to the INSPIRE Registry helpdesk here: INSPIRE-MIF/helpdesk-registry#5

After it was prematurely closed (see the explanation provided in incident 5), I raised it again here: INSPIRE-MIF/helpdesk-registry#10

@Ana-SGA You may also comment there and ask for a status.

As there is an issue in the INSPIRE Registry with the IUCN Category V (former known as Natural Parks category) , that may impact you as well, I raised also this incident INSPIRE-MIF/helpdesk-registry#11

No answer or reaction was yet received, probably because the INSPIRE Registry Helpdesk is askig for country officials to raise incidents and not data providers. This is what was replied:

<<Please remember that requests impacting the content of the INSPIRE registry are reserved exclusively to the appointed submitting organisations. Contact details of the appointed submitting organisations are available here: https://github.com/INSPIRE-MIF/helpdesk-registry/blob/main/submitting-organisations-list.md >>

So even if there are mistakes or even if the INSPIRE registry is incomplete, the helpdesk is not considering to make the corrections/additions by themselves, but is asking for a national official represententative to ask for it.

In Croatia is Tanja Rodin from State Geodetic Administration (tanja.rodin@dgu.hr). From JRC it is andrea.perego@ext.ec.europa.eu. None of them are registered users in GitHub. But @michellutz from JRC is registered in GitHub and is also present on the list indicated by the INSPIRE Registry Helpdesk. So you may adress to him this issue.

How much time it takes to explain to the national representatitive and her/him to agree to submitt officialy such a request, and then to expalin again what to reply in order for the problem to be fixed and not just checked, it depends from country to country and the willingness and understanding of the INSPIRE Registry helpdesk to fix the issues.

I would rather think that the issue should be raised to the INSPIRE Validator team and not to the INSPIRE Registry, as the error occurs in the Validator that is based on TGs and because the INSPIRE Registry Helpdesk explained that legally they are not obliged to add those layer names, even if they should be added according to TGs or according to technical/logical limitations. As you may see the INSPIRE Registry Helpdesk is mentioning that the INSPIRE Registry is not taking into consideration the Technical Guidelines, but only the Commission Regulations and the text of the INSPIRE Directive.

[iuriemaxim]

@Ana-SGA The incident related to the addition of harmoinised layers names for Protected Areas in the INSPIRE Registry INSPIRE-MIF/helpdesk-registry#10 was tagged today with "under analysis" and "change request" tags.

The incldent related to the incorrect link for the Category V IUCN INSPIRE-MIF/helpdesk-registry#11 was treated and closed.

[iuriemaxim]

@carlospzurita Can you please explain why this incident is marked as ”discussion”. There is a clear bug in the INSPIRE Validator as harmonised layer names that are defined in the Recomandations of the TG for Protected Sites, are triggering errors in the Validator.

@fabiovin If a user creates a service that is also implementing recommandations, the Validator should provide errors?

[fabiovin]

Dear all,

please refer to this comment in issue #39 which explains why we decided not to include any changes in the latest release.

We are collecting all your comments to find a clear and agreed solution.

[iuriemaxim]

@fabiovin There is a significant difference between the two issues: one is a request for removing the tests for harmonised layers and this one is reporting a bug in relation with harmonised layers names.

My question was: If a user creates a service that is also implementing recommandations, the Validator should provide errors?
Of course that I understand the other incident. But these two are not related at all and should not be treated toghether.

The issue #39 is a request for relaxation of the tests, in such a way that validation of layer names should pass the test (manual/automatic - this is not important as the result is the same: non harmonised layer names will pass the test). And this is quite against the provisions of the legislation.

The present issue is a bug related to the fact that the harmonised layer names are not passing the tests if they are not registered in the INSPIRE Registry. But they are present in the recomandations of the TGs and they should be added in the INSPIRE Registry as well, not just becuase of the provisions of the TG, but also because of the provisions of the Comm Regulation 1089/2010 which is listing the code lists for various Protected Areas categories and classifications. So if an user is correctly implementing the TG, including its recomandation, the INSPIRE Validator is triggering an error that should not be triggered. It is quite strange to trigger errors if recomandations are implemented. Repairing this bug is not against the legislation.

[arbakker]

I agree with @iuriemaxim there is significant difference between this issue and issue #39. Conflating these two issue into one will not help the discussion, on the contrary.