[XMLBean 2.3] How to generate XML file with start tag and end tag for empty element

[Terence Hong]

I am doing a task for data transfer to other system by using XML.
I got the schema and the sample XML file.

In the sample XML file for the empty element it will show the start tag and end tag like the follow one
<Address2></Address2>

However, when I set an empty String to this element and the XML generated from my program is like this
<Address2/>

I am using XMLbean 2.3 and java 1.5 for development.
Is there any method that can make the generated XML file contain the start tag and end tag?

the xml schema for the element list below
<xsd:element name="Address2" minOccurs="0"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:maxLength value="40"/> </xsd:restriction> </xsd:simpleType> </xsd:element>

[William Brogden]

Short answer: No

According to XML Infoset standards the two forms are equivalent and should be handled the same by any conforming XML parser.

I would not worry about it unless the other system complains.

Bill
(this forum has had some long conversations about this topic in the past)

[Drew Liscomb]

William Brogden wrote:...
I would not worry about it unless the other system complains.

"... Aye, there's the rub." To_be,_or_not_to_be

We do run into this. While XML claims it's equivalent, the other company's code from Parsers-R-Us dictates that it has to be in the <Element></Element> format.

Thus we can

get a new job

badger the other guy to fix their code, delaying the project indefinitely, and causing us to lose our job

make our code work with their half-witted parser

<hitting the "submit" button>

[William Brogden]

You have my sympathy.

If this was my problem I would create some sort of stream filter to read the existing XML output stream or file, locate empty elements and patch the output to the desired style.

How is this transfer process implemented?

Bill

[Drew Liscomb]

A splendid idea!

XMLBeans implements the XML source as a Reader, so it may be trivial to intercept that stream for this case. Jakob Jenkov's TokenReplacingReader might fit the bill nicely. We send the Reader contents to the remote endpoint via HTTP.

Thanks for the jolt.