[DFDL-WG] Unparsing - Pad to "big enough length to fit..." - can it be achieved in DFDL?

[Mike Beckerle]

I have a format where fields are supposed to be padded so they all have the
length of the longest one.

I.e., something like this with fields terminated by | chars

FIELD1|FIELD2  |ST|PH          |
ABC   |CAPE COD|MA|888-999-0000|
DEFG  |BOSTON  |MA|-           |

I believe I can warn if all the participants in a column of this tabular
thing don't have the same length. I would just set a variable with the
length of the first row, then on subsequent rows (parsed with a different
element in the schema) I would verify that the length equals what is stored
in the variable by way of an assertion. I believe this is what
recoverableError kind is for actually, when you have redundant information
you want to warn about.

The problem I have is unparsing. How in DFDL I could determine how wide to
pad each field before unparsing it. The spec requires me to measure the
width of the fields (including that quasi-header row which is first, and
measure how long each field is, then pad them to that maximum.

I believe there is no way to do this currently in DFDL, because there is no
way that an expression can refer to more than one record, nor any way to
iterate or operate over sets of data.

Instead an application must be written which can use DFDL v1.0 but the
application has to provide some of the smarts.

In this case, the application would have to walk the infoset and determine
the maximum length for each such field, then provide these length maximums
to the DFDL schema by way of externally set variables.

Is there any other way? Second issue: In addition, the spec of my format
requires the total maximum length for all the fields of a row to be at most
72 characters long.  When unparsing, we don't evaluate assertions. So how
can I test this?


--
Mike Beckerle | OGF DFDL WG Co-Chair
Tel:  781-330-0412
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20121114/3b0e9368/attachment-0001.html>