Comments inline. ________________________________
I'd like to fully understand the name of this property -- separatorSuppressionPolicy -- and the names of its values: 'never', 'anyEmpty', 'trailingEmpty', 'trailingEmptyStrict' Here’s how I interpret the names: separatorSuppressionPolicy: the purpose of this property is to state what the policy is regarding when separators should be suppressed. For example, when data is empty, are separators required to be present or can they be absent (suppressed)? “Suppressed” means “not present/absent”? Do you agree with this interpretation of the name? Yes. We renamed this property a while back. It was just "separatorPolicy" which was just not specific enough. never: separators are never suppressed. Do you agree with this interpretation of the name? I agree with what you've said. The problem is how "never" is "never". By "never" here there is a specific interpretation for arrays of elements having min/max occurs when that min/max occurs is being used (not ignored or just for validation), which is that "never" means all separators for maxOccurs occurrences must appear (and are created when unparsing.) trailingEmptyStrict: separators on empty trailing data (empty data at the end of a sequence) must be suppressed. The name uses the word “Strict”. Does “Strict” mean “must”? Yes strict means "must". We use strict/lax in a few places in DFDL. This is following an XSD precedent which uses strict/lax in this way. trailingEmpty: separators on empty trailing data may be suppressed. Since the name does not use the word “Strict” then that means “may”? Yeah, probably should have been trailingEmptyLax to be clear. anyEmpty: separators on any empty data (not just trailing data) may be suppressed. Do you agree with this interpretation of the name? Yes. The challenge with these is that they sound simple, but combined with the complexity of what DFDL means by "empty" it becomes seemingly complicated. I think you have to first understand "empty" as a concept in DFDL, because this is type-specific with a bunch of rules that differ for string/hexBinary from other types. Empty and "zero length" are not the same concept in DFDL. If dfdl:emptyValueDelimiterPolicy is not "none", and the element has an initiator/terminator that is part of the empty representation accordingly, then zero-length means "absent", and "empty" requires some non-zero-length syntax to express. So if I have a data stream like: 1,2,,,,,,,,,, Is that a bunch of elements with empty string as their value? Or a bunch of nilled elements? Or are those data elements absent, where the syntax just requires or tolerates the extra separators? All these have to be (and are) expressible in DFDL because there is data with all of those conventions.
