[
https://issues.apache.org/jira/browse/DAFFODIL-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2977.
--------------------------------------
Resolution: Won't Fix
I think it's wisest to not change this behavior. We haven't changed how we
output anything, so making this change has the potential to break things, and
we don't really gain much.
I think think for object based infosets (e.g. JDOM, W3CDOM), creating explicit
"Text" nodes, with an empty string value is a bit more explicit about a field
being a string value with zero length. Having no child is technically the same,
but I think being explicit where possible is probably a bit better.
I'm going to mark this as Won't Fix. Happy to reopen and reconsider if there
are any other opinions.
> Empty XML element behavior has changed. Needs to be specific.
> -------------------------------------------------------------
>
> Key: DAFFODIL-2977
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2977
> Project: Daffodil
> Issue Type: Bug
> Components: Back End
> Affects Versions: 3.10.0
> Reporter: Mike Beckerle
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 4.1.0
>
>
> XML output used to be `<foo></foo>` but now is `<foo/>` or vice versa.
> Needs to be definite one or the other. (I recommend `<foo/>`
> For any XML outputter, we need to control this behavior so that it is
> definitely one or the other and doesn't change from release to release.
> It's also possible that we should be special casing the filling in of
> string-type elements so that if the string value is length 0 we don't output
> any child at all. Filling in a child string object inside a DOM or JDOM node
> object where that child string is of zero length is going to perhaps cause
> this `<string></string>` vs. `<string/>` behavior. But in XML these are
> indistinguishable, so we should catch this case and not attach the child at
> all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
