[dfdl-wg] simple way to study hard DFDL example problem - IBM Format VS rec ords as XML

[mike.beckerle at ascentialsoftware.com]

I believe you and Jim are actually disagreeing. Jim is saying he's still
optimistic that this transformation, even though complex, can be expressed
directly in DFDL. You are saying this would require XSLT or a Java program
or whatever to do it.

> 
> Mike you say you are aware of 19 such legacy formats, and I 
> bet there are more. Well IBM's broker has no specific support 
> for any of these, nor have we been asked to incorporate them 
> into our message model. Maybe we should play the percentages 
> game - if we see enough different subsystems that use the 
> same cryptic format then it becomes worth building the 
> support into DFDL.
> 

Ascential supports 6 or 7 of these formats today. Batch systems will
encounter this more than online. You get them when a mainframe job writes
out a tape on a mainframe, and then you read that tape on a unix tape drive
either directly or first into a file. Alternatively, you pick up a mainframe
file via FTP or some such and directly operate on it on other systems.
Mainframe software handles all the VS block and and such stuff in the lower
layers as you know (not to mention the tape label) unix software does none
of this, you just get the raw bytes.

My point is not as much about these 19 or more particular formats, but the
issue of how much complexity we go after.

In the past we've looked at things like logical arrays with
run-length-encoded representations and the suggestion has been there that
DFDL might be able to directly express this transformation without need to
go outside DFDL. 

I've come to believe there are certain limits to this complexity and I think
perhaps tree-shape compatibility is at the core of them. Building a DFDL
description for data that ultimately requires an LR(k) sophistication parser
to correctly interpret the data is clearly a non-starter it seems. Where
this line is drawn is important. 

...mikeb




...mikeb