XmlObject.xmlText(XmlOptions) outputs xsi:nil="true" where schema definition is minOccurs="0" and default value for nillable="false"

• Key: XMLBEANS-220
• Type: Bug
• Status: Closed
• Resolution: Cannot Reproduce
• Priority: Major
• Assignee: Unassigned
• Reporter: James Webster
• Component/s: XmlObject
• Affects Version/s: Version 2

Description

We have defined a type in the schema as...

<xsd:complexType name="MyType">
   <xsd:element name="mandatoryElement" type="xsd:string"/>
   <xsd:element name="optionalElement" minOccurs="0" type="xsd:string"/>
</xsd:complexType>

According to the XML Schema specification, false is the default value for the optional 'nillable' attribute on xsd:element. So the 'optionalElement' element is nillable='false'.

We instantiate an instance of the MyType class, set the mandatory element and get the value of xmlText()...

MyType type = MyType.Factory.newInstance();
type.setMandatoryElement("someValue");
String xmlText = type.xmlText();

The value of xmlText generated by XMLBeans v2.0 is...

<MyType>
  <mandatoryElement>someValue</mandatoryElement>
  <optionalElement xsi:nil="true"/>
</MyType>

BUT, we would expect (given that optionalElement is NOT nillable) to see the following...

<MyType>
  <mandatoryElement>someValue</mandatoryElement>
</MyType>

Our investigations into the XMLBeans API suggests that it is not possible (via XmlOptions, etc) to suppress the xsi: attributes, so we believe this may be a bug? We are at no point explicitly setting the optionalElement to null.

Comments

Is anyone else experiencing this? It causes the generated XML to fail validation which seems like a serious issue.

[Radu Preotiuc-Pietro]

I will first say that this is not what I am seeing when running your code. I don't get the <optionalElement> printed out.

I will also say that XmlBeans does not guarantee that valid documents are generated following a certain succession of method calls (that would be next to impossible) but on the other hand you "can" generate any infoset you like, which is one of XMLBeans' strengths.

As far as xsi:nil behaviour, the decision that we made for reasons of simplicity to define behaviour was:
1. XMLBeans never creates or deletes elements, except in direct respose to a user's action
2. Elements explicitly set to null are represented as xsi:nil="true" without regard to Schema (and we also have a "remove" method to delete elements)

So I guess this is "no repro" as a bug for me (however I have tried it with xmlbeans-2.2.0). Can you try it quickly with 2.2.0 as well (even though from what I remember this behaviour hasn't changed since 2.0)

[Adam Lewandowski]

You are correct, if the element is not explicitly set to null, then the element is not generated at all (when maxOccurs=0). This works (at least in 2.2.0), thanks!
I was unaware that XmlBeans does not guarantee schema compliance. It's not the end of the world, but I was expecting that since I fed it the schema to begin with it would stick to it when generating output.

[Radu Preotiuc-Pietro]

Glad it works now!

Schema compliance is too general a word to use. XMLBeans does guarantee Schema compliance in the sense that if you pass in a Schema, it is processed if correct and then XML documents are correctly validated against it, which is kind of the essence of Schema.

What's not guaranteed is that generating documents from scratch by using APIs will result in valid documents, which is far less problematic of a restriction. The main idea behind this is that people may want to generate invalid documents for various reasons (like intermediate revisions of a document that is not yet final). While in general it is prohibitively difficult to ensure that all documents generated are valid, it would be possible to add an option so that some reasonable attempts are made at serializing something that is valid, that would be useful.

[Wing Yew Poon]

Based on the comment thread, this does not appear to be a bug, probably user error.