zREST zDFDL to suport zDFDL expression for the Code Page Encoding Attribute (and DFDL variable for operationId)

z/TPF's zDFDL transformation needs a parameter to specify Code Page of the target transformed object so that EBCDIC 1047, subset of P1024 Terminal Characters in EBCDIC 1047, and UTF-8. This would avoid loading multiple zSwagger Files and zREST System Definition Files to support multiple implementations of the same zREST Operations that only differ in the target code page and supporting target application.

Background from z/TPF's Brad Kadlecik:
I also reviewed the DFDL spec for the dfdl:encoding attribute and it mentions that this can be a DFDL expression. zDFDL currently does not allow a DFDL expression for this attribute in our implementation however it would not be difficult to add it. So an alternative idea (instead of creating 2 DFDL files that just differ for encodings) is that a single DFDL file could be used and we (IBM - REST provider/consumer) can create a DFDL variable that contains the operationId such that one can decide which encoding to use based on an operationId. Another IBM provided DFDL variable could be the status code such that different message formats can be described in a DFDL file for different response data based on status code.

So instead of having dfdl:encoding="x-ibm-1047-s390" (the default) or dfdl:encoding="utf-8" in a separate file; this can be expressed in a single statement like:
dfdl:encoding="{if ($tddt:operationId eq 'newService') then 'utf-8' else 'x-ibm-1047-s390'}"

This is a runtime operation that would have to be performed on each string that may differ in such a way but up to you of course on how you'd want to manage these differences between the services.
The encoding for the HTTP body can be specified in a HTTP header like "Content-Type: application/json; charset=utf-8" but this is not universally recognized since the charset attribute is normally used for a text MIME type such as "text/plain; charset=ascii" rather than application MIME type in which the charset is understood. For example, MIME type of "application/xml" depends on it being specified on the first line of the XML document; whereas, MIME type of "text/xml" can use charset to specify it instead. There is no MIME type of "text/json". The REST provider support does look at this header to determine whether it is an XML or JSON body but charset is never checked for. The only allowable encodings for a MIME type of "application/json" are UTF-8, UTF-16, or UTF-32. In reference to this MIME type, the charset attribute is not used but rather the first character of the JSON is examined to determine between the 3 unicodes with UTF-8 being the default. The DFDL and JSON parsers on z/TPF would need the JSON document to be in UTF-8 to handle it properly though.