[dfdl-wg] Plumbing document

Robert E. McGrath mcgrath at ncsa.uiuc.edu
Thu Sep 1 13:03:26 CDT 2005


Greetings,

I took a quick glance at the streams and semantics notes sent yesterday.

There is obviously common ground here, and both meshed with my own
half-baked thinking.

They did make me disagree with one part of the approach, which may
make things a little simpler.

So here's my thinking.

IMO, there is no reason to worry about a detailed definition of streams.

It seems to me that we are simply dealing with sequences of bits, which
can be streams or not.

So I see the universe of DFDL as:

   sequence of bits ==> computer science data type ==> seq. of bits

where CS data type is "byte", "int32", etc. (Z, G, et al. in the semantics
note)

The DFDL talks about the CS data types, with decorations to tell how to
do the transformations to bits. I think that's all DFDL does (which is
plenty!)


Now the second place that "streams" enters the picture is to deal with
XML's notion of the order of elements, which DFDL is trying to use
to deal with the order of the bits.  

(I think this confuses me because it is overloading XML's notion of an 
XML file with the organization of the described files.  You can make 
it work, but it's not really clean, at least to me.)

To me, it is more natural to define a notion of a "sequence of CS data types",
i.e., the elements. The decorations indicate where the bits for each
element are (i.e., each element has it's own sequence of bits, not necessarily
from a continuous stream).  

This is more general than a stream (it can accomodate random access), and 
probably can be stated as a simple mapping.  


So the summary is:  

I think it would simplify the abstractions to not talk about streams.

Instead, we should talk about sequences of bits, one for each element,
and a model associating elements with bits.


I hope this isn't to far off beam.

Thanks for your attention.





More information about the dfdl-wg mailing list