Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of AbstractListField.Accessor#hasSetValue questionable for mandatory lists in XML attributes #1823

Open
winfriedgerlach opened this issue Nov 4, 2024 · 0 comments

Comments

@winfriedgerlach
Copy link

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:

image

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:

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant