-
Notifications
You must be signed in to change notification settings - Fork 119
Description
We encountered an edge case caused by the implementation of AbstractListField.Accessor#hasSetValue
: With this commit, the implementation was changed so that hasSetValue()
returns an expression that is sensitive to the list being non-empty:
Our problem is that in our XML schema we have a mandatory attribute (use="required"
) of a list type with no restriction on the list's size. This means that an XML document with the attribute being present but empty validates successfully, while an XML dockument lacking the attribute fails validation against the schema. So an empty attribute is semantically different from a missing attribute, in contrast to the AbstractListField.Accessor.hasSetValue()
implementation.
The problem becomes apparent when, e.g., using org.jvnet.jaxb:jaxb-tools
' CopyablePlugin which uses hasSetValue()
twice:
- directly in the CopyablePlugin
- and indirectly via PropertyFieldAccessor#toRawValue (lines 219 and 223)
As the generated code does not copy empty attributes, a valid XML document (with an empty attribute of list type) becomes invalid when unmarshalled, copied, and marshalled again.
I do understand that lists of XML elements do not have the same problem (empty lists and "null" lists of XML elements are indistinguishable). So this problem really only applies to lists in XML attributes.
What do you think, how could this be solved? Should lists from XML elements be treated differently than lists from XML attributes? Or should users of your library not rely on hasSetValue()
like org.jvnet.jaxb:jaxb-tools
does? If so, what API could they use instead?
Thanks in advance!