apigee x json to xml - fixing declaration header and empty tags

I am using apigee to convert from json to xml

1.  I cannot find a way to modify the response xml declaration header

every time it comes as 

 

<?xml version="1.0" encoding="UTF-8"?>

 

however I want to set the standalone property so it comes back as:

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

 

I cannot seem to find this anywhere in the docs.

 

2. I also want to replace auto closing tags with start and end tags is this possible ? cannot locate inside the documentation

{
  "users": {
    "user": [
      {
        "firstname": "test",
        "lastname": ""
      },
      {
        "firstname": "test2",
        "lastname": "abc"
      }
    ]
  }
}

e.g this comes back as in xml:

 

<users>
 <user>
  <firstname>test</firstname>
  <lastname />
 </user>
</users>

 

is there a way to enforce this to include closing tags to become

 

<users>
 <user>
  <firstname>test</firstname>
  <lastname></lastname>
 </user>
</users>

 

 

0 3 113
3 REPLIES 3

Regarding #1, as far as I know there is no way to influence the content of the XML declaration line. You can ask to exclude the declaration line completely, or not. But you don't get to specify what goes in the line.

Regarding #2, the two are equivalent. There is no way to affect that, either. As far as I know.

What problem are you really trying to solve?

My understanding of standalone="yes" is that it tells readers that the information inside the document can be faithfully retrieved based only on the internal DTD, i.e. the document can "stand alone" with no external references. (cite) This further means the standalone=yes declaration is relevant only if there is an internal DTD. There is no internal or embedded DTD in this case, so standalone attribute does not matter.

Which brings me back to my question: what problem are you really trying to solve?

You seem to be hoping to get the JSONToXML policy to generate an XML document that exactly matches the form of an example XML document. But that is not required by the XML standard. The XML standard says that document processors (readers) must rely on the XML Infoset - that is, the information contained in the document, not the precise string format. Therefore

<element></element>

is exactly equivalent to 

<element/>

...and document processors must not distinguish between the two.  There are lots of other implications. Ignoring the standalone="yes" in a document with no Internal DTD is another example. 

If the system that will consume the XML output of this policy is not treating these two forms the same, then that system is in error.  It should be fixed. I would be very surprised to learn of a system that behaves this way, however.  Unless it is a naive processing of XML that actually parses the string, instead of dealing with the XML infoset.

The main idea behind this is we have rewritten a very legacy XML service to  a new JSON api, we are then attempting to use apigee to convert the new JSON api response to XML format (one of the benefits of apigee).

Due to the age of the legacy api and the users integrating we would like to have a 100% match in response when comparing the new and legacy api (these are mostly the only two differences that dont match), like you suggest with the naive processing of XML this could be an issue for our users (we have no control/knowledge over how they are using the response).

looking at this I assume there may be some kind of workaround using javascript to manually edit the response, however it may be quite a hack and maybe we should be better spent to look into just convering our new api into actual xml instead of relying on apigee to convert in this case

 

 

I agree that modifying the XML with JavaScript and string manipulation would be sort of hacky. 

Also I disagree that "the two differences" you have identified will plausibly be impactful for your users.  No proper, correct system will distinguish between these.


@rgsoftware wrote:

we have no control/knowledge over how they are using the response


Yep, and they could be processing the XML and counting whitespace between elements too, and how much indenting there is.  But none of that is valid, for handling XML, and they shouldn't do it.  It is highly unlikely that any user IS doing something that will be able to detect a difference. 

But good luck with whatever you decide.