[dfdl-wg] Plumbing document

[mike.beckerle at ascentialsoftware.com]

Comments on the document.

It would be most helpful if all sections were numbered so that comments can
be made specific, but let me do it this way for now:

Section 1.Function.Use

About "runtimeOccurs". I think the prefix "runtime" is part of recognizing
that there are static parameters and dynamic parameters. We think of
byteOrder as something static or usually static, though in reality, it can
vary based on an indicator found in the file, witness the UTF-16 character
set which can have a byte-order-mark at the beginning to indicate whether it
is really UTF-16BE or UTF-16LE.

The question is whether the separation of static and dynamic as the usual
usage pattern for each parameter is tight enough that we feel comfortable
putting something like "runtime..." in front of the name. 

In fact the parameters runtimeOccurs and runtimeValue probably should be
renamed to occurs and value to reflect that they can be either static or
dynamic just like byteOrder can be.

I like better the proposal you have in section 3.Parameter Properties where
you have two states for each parameter, dynamic static, and scoped
not-scoped. I'd rather not encode the status of the parameter with respect
to these two states in its name. 

Section 2

I want to noodle with the mathematical semantics of reader/writer/filter a
bit here. I think this is all not crisp enough yet. In particular, I want to
break streams up into sets of values, and separate out keeping track of
cursor position. This will let us make absolutely clear what is going on
with what I called "length protocols" in previous emails. So I would
redefine reader to take in an input (set of values with positions), a cursor
position, and to compute a value, and a new cursor position, but not to have
any side-effects, i.e., a pure function. A writer takes a stream (set of
values with positions), a current position, and a value, and produces a
stream (with more members in the set) and a new position. 

I need to work on this more and present it back to you all.

Section 3

The scoping scheme you describe here makes sense to me. However, I worry
about order sensitivity. Suppose I moved the top level bigEndian annotation
to a position textually after the definition of xType. Would xType now be
without any annotations? Or does order not matter? Order sensitivity of this
kind is consistent with programming-language semantics which generally
considers both order and nesting level together when considering scope of a
declaration. 

I believe we will want the ability to do both:
1) introduction of global defaults for rep parameters
2) introduction of reusable complexType definitions which *take no position*
on rep parameters such that their use points inherit local control over rep.


To do this in your example I'd have to be able to get the xType's definition
out of the scope of the global declarations somehow. Just switching the
order around would do it if we're comfortable with that.




> -----Original Message-----
> From: Martin Westhead [mailto:martinwesthead at yahoo.co.uk] 
> Sent: Wednesday, December 08, 2004 3:16 PM
> To: dfdl-wg at gridforum.org
> Subject: [dfdl-wg] Plumbing document
> 
> Hi Folks,
> 
> Sorry you didn't get a round up Susan, I'm afraid we were not 
> prepared for it. I was on the call this morning ready to 
> summarise events but I was the only one on.
> 
> Based on discussions, yesterday afternoon I have drawn up the 
> attached document. The starting point for this was stuff that 
> was agreed but I have tried to flesh it out and push the 
> ideas in various directions.
> 
> I have tried to suggest a what would be required to define 
> and use each of our various operation elements. I have also 
> proposed a possible solution to the scoping problem.
> 
> This document may not make much sense to those who were not 
> at the face to face and for that reason I do not propose to 
> put it on Grid Forge yet. It should provide some material for 
> our GGF13 submission.
> 
> It would, of course be very useful if those at the F2F could 
> take a look and comment before our collective memories of 
> what we discussed fade.
> 
> Thanks,
> 
> Martin
> 
> (Doc is in PDF because I'm not confident that OpenOffice -> 
> Word will preserve the diagrams. If anyone wants to make 
> detailed comments I'll send them a Word version too.)
>