[FEATURE REQUEST] Support an XML-driven State renderer

[johnnybubonic]

Is your feature request related to a problem? Please describe. I know it's the current fad to hate XML. Hear me out - most people who hate XML are simply unaware of just how powerful it can be natively.

How many GitHub issues are triaged that are due to YAML errors due to chomped or inconsistent whitespace, a misunderstanding about the significance of : in the middle of some strings, multiline blocks, etc.?

Wouldn't it be great if there was a format that didn't care whatsoever about indentation levels or title string content?

Wouldn't it be even better if that format natively had standardized mechanisms for:

• attributes/parameters of states separate from their content (file.managed's contents vs. name, for instance)
• referencing a specific state - or ANY specific COMPONENT of a state - in a completely non-ambiguous manner (think of how much more clear the error messages could be)
• including remote states by URL (think of how much more simplified formula inclusion could be)
• a cooked-in validator - with (optional) typing
  • the possibilities for bug reduction in state definitions for this are endless. i can provide examples if you're in doubt.
• native support and parsing/generating tools, plugins, syntax highlighters/checkers, and libraries for just about every language, IDE/editor, and code input form out there - no need for a custom parser

Describe the solution you'd like Ladies, gents, and other: the answer is XML. Specifically, something I think my be catchy: ".slsx" (Jinja-wrapped XML, which renders to XML defined by a Salt schema).

Describe alternatives you've considered Not going crazy because of a stray spacebar collision here and there and obtuse and inconsistent error messages, not succumbing to the forever struggle between cleanly rendered states and programmatic covering of a wide and robust infra.

(It hasn't been going well. And I'm probably what would be considered a Salt veteran.)

Additional context Just a quick, small demo; let's look at what, say, a file.comment state might look like in SLS (jinja|yaml):

Replace Some Silly Decisions:
  file.comment:
    - name: '/some/path/to/file/to/comment.txt'
    - regex: '^some_undesired_config_directive=a_bad_value$'
    - char: '#'
    - backup: '.DO_NOT_USE'
    - ignore_missing: True

could look like the following in SLSX:

<!--- ... (presumably other states here) --->
<file>
  <comment id="Replace Some Silly Decisions" regex="^some_undesired_config_directive=a_bad_value$" char="#" backup=".DO_NOT_USE" ignoreMissing="true">/some/path/to/file/to/comment.txt</comment>
</file>
<!--- ... (presumably other states here) --->

Now, many people at first say "That looks horrible, I can't read that! YAML is so much nicer!"

Ah, but unlike YAML, the state author can format exactly how they like it.

How about something like, say, this?

<!---
    ... (presumably other states here)
--->
<file>
  <comment

                    id="Replace Some Silly Decisions"
                    regex="^some_undesired_config_directive=a_bad_value$"
                    char="#"
                    backup=".DO_NOT_USE"
                    ignoreMissing="true"
                    >

            /some/path/to/file/to/comment.txt

  </comment>
</file>
<!--- ... (presumably other states here) --->

It evaluates to the exact same as above. Parser don't care; parser don't give a f- (A document/element's schema can define how each element type should handle leading/trailing whitespace in content).

I know this whole thing seems silly, but I'd recommend tossing the idea around. Think about the benefits I mention above. Mull on it a while.

There is, of course, the stdlib xml module, but I'd highly recommend lxml instead. It would make parsing and validating states an absolute breeze, and has tightly integrated XSD (XML Schema Document) and namespace support built right in.

Come, imagine a better future for state definitions with me.

Please Note If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.

[OrangeDog]

You could start right now with a custom renderer to test how well this works in practice.

If there's something you can't do that way, then it's going to need an SEP for the core changes.

Wouldn't it be great if there was a format that didn't care whatsoever about indentation levels or title string content?

There are several of those formats already available.

[OrangeDog]

I suspect you're going to hit difficulties once you get to anything that takes complex structures as input. How should a module.run state or an unless requisite look in XML?

Your proposal to map kwargs as attributes fails as soon as you need to differentiate between a string and a number, for example. Not to mention a list.