[XMLBEANS-261] Classes generated for schema types which have inheritance by restriction could better implement the restricted methods

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: Version 2.1
• Component/s: Binding
• Environment: All
• Assignee: Unassigned
• Reporter: Lawrence Aston Jones
• Created: 04/Apr/06 07:33
• Updated: 18/Aug/20 17:02

Description

Consider e.g. the schema in http://davidbau.com/archives/2003/12/18/the_design_of_xmlbeans_part_3.html, "Inheritance by Restriction" (although it's easier if you change the types of the elements to be "xs:string"). The type derived2 derives by restriction from type derived1 and the restriction is such that an element which was optional in derived1 must no longer be present in derived2.

Currently a getter / setter set of methods are generated on derived1 and not overridden on derived2. Hence derived2 has the same functionality as derived1 i.e. the setter works and sets an element which should not be present in derived2, and the getter will get that element if it is present.

According to the above article the getter should always return null. The functionality of the setter is not defined.

This JIRA is to request updating this functionality. The setter for derived2 should override the derived1 setter and could do:

a) nothing (i.e. silently not set anything and return)
b) return an UnsupportedOperationException (or maybe a similar RuntimeException specific to XmlBeans - note: a RuntimeException would not require changes to the throws clause)
c) actively make sure that there are no such elements in the store and return (either an exception or just return) after that

The getter too should be overridden and should:

a) just return null, or
b) actively make sure that there are no such elements in the store and return null

But there are other things to consider:

If, say through the cursor API, the user does manage to insert this element into the underlying store - should the getter still return null? Should a call to xmlText() or toString() or any other method of producing the XML write out the element as it is in the store (which is the approach we've taken for everything else) or should we try to remove any such elements before printing out?

What if the derived1 type allowed maxOccurs>1? Then we also have to do the above for array setters/getters (and the list getters/setters for JDK1.5).

What happens if someone sets up derived3 which inherits from derived2 by extension and "re-enables" those elements which were in derived1?

Offhand I agree that the current functionality of allowing the setters/getters to inherit the parent's functionality is odd and not very user-friendly. But Java does not map easily to "inheritance by restriction" and I think we need to figure out (at least) all the things above before we implement an update to the functionality.

Issue Links

• is related to: XMLBEANS-550 Type change by restriction not implemented properly in Java API