mbeckerle commented on a change in pull request #218: Implement
dfdl:choiceLength='explicit'
URL: https://github.com/apache/incubator-daffodil/pull/218#discussion_r291429717
##########
File path:
daffodil-core/src/main/scala/org/apache/daffodil/grammar/primitives/ChoiceCombinator.scala
##########
@@ -48,9 +50,22 @@ case class ChoiceCombinator(ch: ChoiceTermBase,
rawAlternatives: Seq[Gram])
override def isEmpty = super.isEmpty || alternatives.isEmpty
+ private lazy val bitsMultiplier = ch.lengthUnits match {
+ case LengthUnits.Bits => 1
+ case LengthUnits.Bytes => 8
+ case LengthUnits.Characters if ch.knownEncodingIsFixedWidth =>
ch.knownEncodingWidthInBits
+ case _ => 0 // zero means can't multiply to get width in bits.
+ }
Review comment:
Yes, there are a few places in DFDL where we have a single property, but
having distinct ones would be better. A problematic area is dfdl:lengthKind. It
would really be better to have separate lengthKinds for complex type elements
and for simple type elements, because they are often different, but uniform.
Typically complex types want lengthKind 'implicit' but simple types 'explicit'
or something else. but 'implicit' is much less used for simple types.
An example that is done properly is textNumberJustification,
textStringJustification, textBooleanJustification, etc. those often want to be
set differently. If there was just textJustification, you'd have to keep
setting and resetting the property for different types of elements even though
the normal pattern is strings justify to the left, and numbers to the right,
booleans... depends on their representation. If it's 1 and 0, then right. If it
is "true" and "false" then left.
So if we introduce a lengthUnits for choices I would suggest it is a
separate property choiceLengthUnits.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
