This is kind of two issues in one. Context is, I need to store a dataset, some of the data is encoded HTML. I need to export this to an XML Export as a string. (This string is used as a parameter in a Stored Procedure (called by Database Connector). I don’t think this bit’s relevant but worth nothing).
So, issue #1 – This is how some of my encoded HTML looks in the XML i am importing
But after I run the Import action, and view the variable in the Debugger, the < has decoded, or is at least being displayed as decoded
I’m finding this difficult to work with, as I have explicitly stored this attribute as encoded HTML.
Issue #2 – After I run the Export action, using the XSD template built for this XML, the same attribute has… half decoded. All the “<” remain encoded, however all the “>” have been decoded. This is consistent throughout the document.
Obviously this isn’t ideal, as my export isn’t reflecting the data I have tried to import. This goes on to cause issues with the Stored Procedure which is my end-goal, as it throws up validation errors.
This is all the Microflow is doing. Create Filedoc, get XML file from a local folder, Import said file through the Import template, Export it to a string, send it to stored procedure.
Can anyone help me understand if this is a bug, or if there are ways around the apparent Mendix auto-decoding that’s happening with my XML Import/Export? Let me know if I haven’t explained anything well, and I can clarify.
I do not see anything weird happening in you post. The one thing that may seem confusing to you is that there are different views on what characters need to be escaped in XML. Escaping > is usually optional (See https://stackoverflow.com/a/46637835). Mendix actually does this properly, while a lot of naive implementations just always escape > as well.
If you wanted to have the literal string “<” stored, your XML would have had to look like this: “<Question>&lt</Question>”.
This is what’s happening:
Issue #1 The value as shown in the Debugger, is likely still encoded, but only shown as decoded. And likely just a design choice by the Debugger-designers. Try writing it to log-file to see if this is indeed still encoded.
Issue #2 I have seen that before, but don't know where...