dfdl:lengthUnits describes the units of the dfdl:length property. If dfdl:length is 5, you need to specify if that's 5 bits, bytes, or characters.
There is also the dfdl:alignmentUnits property, which describes the units of the dfdl:alignment property. This naming convention allows for different properties to be defined with different units. So for example, you could describe length in terms of bits, but alignment in terms of bytes, which might feel more natural than if everything always had to be in bits or bytes. Also, note that alignmentUnits does not support "characters", so units="characters" would't make sense for alignment. Those are currently the only two properties with units, but you could maybe imagine new properties added to the spec that might also have some sort of unit that might differ from length or alignment. So you'd have something like dfdl:newProperty and dfdl:newPropertyUnits to make that distinction clear. On 1/6/20 10:21 AM, Costello, Roger L. wrote: > Hi Folks, > > If we want to describe a text data format, then we specify that the data has > a text representation, i.e., > > representation="text" > > To describe a binary data format we do this: > > representation="binary" > > The "representation" terminology seems reasonable to me. > > Next, we want to describe the fundamental (atomic) units of the > representation. For the text representation the units are characters. For the > binary representation the units may be either bytes or bits. It seems to me, > that "units" is the appropriate term for this, i.e., > > units="characters" > units="bytes" > units="bits" > > Sadly, that is not the term that DFDL uses. Instead, it uses "lengthUnits" as > the term, i.e., > > lengthUnits="characters" > lengthUnits="bytes" > lengthUnits="bits" > > Why? That terminology makes no sense to me. Can you give a rationale for why > the term is "lengthUnits" and not "units"? > > /Roger >
