Preserve SCL validity

[ca-d]

Is your feature request related to a problem? Please describe. Sometimes a user (i.e. a plugin) requests an editing action which we can tell would make an otherwise valid SCL file invalid, e.g. regarding schema validity, functional validity or the like.[^ex]

Describe the solution you'd like I want to be given the following four options for what to do about non-validity-preserving editor actions:

• try to fix them up automatically[^fix], presenting opportunity for manual intervention only where no automatic fix is found
• don't do anything automatically, but let me choose among available fixes and manual intervention for each issue encountered
• dismiss them outright, showing an error message instead of committing the action
• commit them as is, warning about invalidity afterwards (current behavior)

Requirements

• [ ] a loadable "quick fix" menu plugin, which
  • [ ] on click, displays a small settings dialog with three choices:
  • [ ] automatic quick fix
  • [ ] manual quick fix
  • [ ] "replace with no-op" quick fix,
  • [ ] wraps the core editor engine
  • [ ] replacing invalid actions and
  • [ ] querying the user when manual intervention is needed.

Suggestions for a specific user interaction I envision a menu plugin that opens a settings dialog on being clicked and otherwise automatically opens dialogues whenever querying the user for manual input.

[^ex]: One example would be renaming an IED to the name of another IED in the same file resulting in an otherwise schema-valid SCL file becoming schema-invalid. [^fix]: Append a sufficiently large number to the IED name in the example above.

[ca-d]

@danyill Does this reflect the status of our discussion as you remember it?

[danyill]

Yes, I found our discussion constructive and what I learnt which led to the closing of #1033 is:

• Significant thought has been put into requiring schema compliance throughout the application.
• There may be workflows where it is useful and necessary to be schema non-compliant. This was initially a surprising thought to me, but from our discussion I have come to realise that schema compliance should not be an overriding objective in itself (we recall Kant since at least one German was involved in this discussion: sich in sich!).

  • 1033 indicates that having a Communication element without a SubNetwork is schema non-compliant. This is debatable, but perhaps having an empty Communication element is a workflow pre-requisite to building the communications structure.

  • Sander gave a good example of a new project file where the user has just created an empty Substation element which is also schema non-compliant, and yet to build a substation one must start somewhere (it does not fall from the sky which seems to be what schema validation implies!)
• Schema compliance perhaps represents more a "what should be in a completed workflow for an SCL" rather then in any transitional stage (I view this as being a deficiency of the standard). This means for OpenSCD that schema compliance is only an ultimate objective, not (necessarily) an objective at every step along the way.
• It is possible that if our OpenSCD workflow is bound too tightly to editing specific elements of SCL rather than meeting the intent of the standard that we are schema non-compliant because have taken a too SCL-centric view of the workflow but I don't think this is generally the case.
• I also take the point discussed recently that it is best for actions not to have endless dialogs of "Did you really mean X and would you like me to do Y". This may naturally result in damage to workflows where the (power) user wants to say "Go away, I'll fix that later". So over-emphasising schema compliance may damage workflow.
• Finally, we discussed the idea of having to be able to do the atomic actions before being able to add a more sophisticated overlay where we detect a user action in a worfklow and decide that there is a possibility of real, unintended harm to the project. It seems best to identify these on a case-by-case basis as this is not "generally true" for all schema validation errors.