Wow! That is very useful information.
Thank you Steve! /Roger -----Original Message----- From: Steve Lawrence <[email protected]> Sent: Monday, February 4, 2019 10:08 AM To: [email protected]; Costello, Roger L. <[email protected]> Subject: [EXT] Re: Best practice for replacing a numeric value with a symbolic value? The first element would be the raw value, followed by two inputValueCalc elements, e.g.: <xs:element name="Storage_Class" type="xs:int" dfdl:lengthKind="explicit" ... /> <xs:element name="Storage_Class_Desc_Short" type="xs:string" dfdl:inputValueCalc="{ if ../Storage_Class eq 0 then "IMAGE_SYM_CLASS_NULL" else ... }" /> <xs:element name="Storage_Class_Desc_Long" type="xs:string dfdl:inputValueCalc="{ if ../Storage_Class eq 0 then "No assigned storage class" else ... }" /> It's a bit inefficient since it needs to evaluate two expressions that are the same except for the strings returned (long vs short), so this particular case might not be the best example. A better example might be a raw integer field that you want converted to both radians and degress since some users might prefer one over the other. So you might have something like this: <xs:element name="angle_raw" type="xs:int" dfdl:lengthKind="explicit" ... /> <xs:element name="angle_rad" type="xs:double" dfdl:inputValueCalc="{ ../angle_raw * ... }" /> <xs:element name="angle_deg" type="xs:double" dfdl:inputValueCalc="{ ../angle_raw * ... }" /> This allows the user to pick which representation of the angle they want, without having to worry about how the raw to rad or raw to deg conversions needs to be done--they can just pick the right element and trust that the scheme performed the right calculations. On 2/4/19 9:58 AM, Costello, Roger L. wrote: > Thank you Steve! > > Your last suggestion is very intriguing: > > It might make sense to use separate elements for each type of > identifier. For example, maybe something like this would be more useful: > > <Storage_Class>0</Storage_Class> > > <Storage_Class_Desc_Short> > > IMAGE_SYM_CLASS_NULL > > </Storage_Class_Desc_Short> > > <Storage_Class_Desc_Long> > > No assigned storage class > > </Storage_Class_Desc_Long> > > How would that be implemented? One field in the input file results in > 4 elements in the XML output. I didn't know that is possible. How to do that? > > /Roger > > -----Original Message----- > From: Steve Lawrence <[email protected]> > Sent: Monday, February 4, 2019 9:52 AM > To: [email protected]; Costello, Roger L. <[email protected]> > Subject: [EXT] Re: Best practice for replacing a numeric value with a > symbolic value? > > I think it really depends on who will use the XML infoset and how they > plan to use it. If everyone in the world knows that 0 means > IMAGE_SYMCLASS_NULL, then maybe you don't need the converted value or > description. Or if no one would ever know what 0 means maybe it makes > sense to only have the description. We've come across formats where > people actually do care about the raw value because that's what they > know and what they are use to, but the converted value is more useful in > certain calculations, so we end up including both the raw and logical values. > > Some things to consider: > > - Certain field types may be easier to filter on than others. For > example, numeric values can be compared in ranges. Maybe someone only > cares about fields greater than 2--maintaining the numeric values helps with > that. > > - Sometimes multiple numeric values map to a single logical value. For > example, maybe 0-4 have unique meanings, but 5-15 just mean > "ILLEGAL_VALUE". If you hide the numeric value, that might pose > difficulties in unparsing so you've lost that information--you now > need to use outputValueCalc to determine which numeric value to > unparse when the logical value is ILLEGAL_VALUE. Maybe there's an obvious > answer, but maybe not. > > It might make sense to use separate elements for each type of > identifier. For example, maybe something like this would be more useful: > > <Storage_Class>0</Storage_Class> > > <Storage_Class_Desc_Short> > > IMAGE_SYM_CLASS_NULL > > </Storage_Class_Desc_Short> > > <Storage_Class_Desc_Long> > > No assigned storage class > > </Storage_Class_Desc_Long> > > The benefit to this is that a user could query and extract exactly > what they want without having to do any string processing. > > - Steve > > On 2/4/19 8:03 AM, Costello, Roger L. wrote: > > > Hello DFDL community, > > > > > > I am working on a DFDL schema for Windows EXE files. > > > > > > There are many places in my DFDL schema where I replace a numeric > value with a symbolic. > > > > > > For example, there is one field called "Storage Class". The > specification enumerates a couple dozen numeric values for this field and > what each value means: > > > > > > IMAGE_SYM_CLASS_NULL (0) No assigned storage class > > > > > > IMAGE_SYM_CLASS_AUTOMATIC (1) The automatic (stack) variable. The > Value field specifies the stack frame offset. > > > > > > IMAGE_SYM_CLASS_EXTERNAL (2) The Value field indicates the size if > the section number is IMAGE_SYM_UNDEFINED (0). If the section number > is not zero, then the Value field specifies the offset within the section. > > > > > > IMAGE_SYM_CLASS_STATIC (3) The offset of the symbol within the > section. If the Value field is zero, then the symbol represents a section > name. > > > ... > > > > > > Do you have a recommendation for the generated XML? Which of the > following is best practice? > > > > > > (a) <Storage_Class>0</Storage_Class> > > > > > > (b) <Storage_Class>IMAGE_SYM_CLASS_NULL</Storage_Class> > > > > > > (c) <Storage_Class>IMAGE_SYM_CLASS_NULL (0)</Storage_Class> > > > > > > (d) <Storage_Class>No assigned storage class</Storage_Class> > > > > > > (e) <Storage_Class>IMAGE_SYM_CLASS_NULL (0) No assigned storage > class</Storage_Class> > > > > > > (f) Other (what?) > > > > > > I am eager to hear your thoughts on this. > > > > > > /Roger > > > >
