[FEATURE REQ] - Export Policy as XML instead of RAWXML

[Banchio]

Please describe the feature.

After exporting from an existing APIM, it is not always possible to programmatically parse policies files as regular xml because of validation errors.
A possible solution would be to include a flag (both in extractor and publisher) to treat policies as regular xml files and not rawxml, something similar to the OpenApi yaml/json formats basically

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[Banchio]

By looking at the code I found that the parameter format=rawxml is added in every type involving Policies (ApiOperationPolicy, ApiPolicy, PolicyFragment, ProductPolicy and ServicePolicy). However it is not clear to me how to retrieve a new config setting from DI in the classes that use these records. Will try to do a debug step-by-step to better understand it.

[guythetechie]

@Banchio - APIM policies support .NET code within the XML files through policy expressions. Here's an example:

<fragment>
  <set-header name="x-request-over-limit" exists-action="override">
    <value>
      @((context.LastError == null) && (int.Parse(context.Request.Headers["Limit"][0]) > 100) ? "Over limit" : "Under limit")
    </value>
  </set-header>
</fragment>

We use rawxml to support these usecases. xml encodes many characters and makes the underlying file harder to read. The fragment above would turn into this:

@((context.LastError == null) && (int.Parse(context.Request.Headers[\"Limit\"][0]) > 100) ? \"Over limit\" : \"Under limit\")

If you want to include an XML parsing step in your pipelines, I would suggest first running the file through a step to escape invalid XML characters, and then parsing the escaped file.

[Banchio]

totally agree that is harder to read but in this format I cannot use Powershell select-xml statement (or anything else that expect a well formatted xml). I tried to replace double quotes within the @( and ) as well as double quotes between @{ and } but gave up on multi-line dotnet code which needed to be escaped.
Especially for programmatically parsing that would be great, I read your comment on the PR will retry when new version will be published then, thanks!