Action: [Geoff] Put together a first pass description
Action: [Mike] Look at DCGs
Action: [Tom] Modifications to the scoping section.

• Discussion of next steps with multidimensional arrays

Report on DFDL session at OGF last week:
- only 6 people attended, of them only 2 were "new people", one from Boeing, one  from National Archives.  Presentation was uneventful.

Doc Edits:
- Geoff Judd reports that uncertainty topic has been split into core + supplement and the results posted on GridForge. The defaults and nulls split is still being figured out. Unclear how to split it up, what stays core, etc.
- Tom Sugden had scoping reorg - Not on call, no report.

Ongoing Actions
- Geoff has written up an example of a group description. Still under review/discussion with Mike and Martin
- Mike has taken a stab at starting a complementary more methodical description. To circulate to Geoff and Martin first.
- Mike grabbed some material on Definite Clause Grammars. Seems to have potential as a formalism for us. The issue is that DCGs are actually programs, i.e., they're runnable when crafted in the usual way, hence, one would expect to have to put in all the details. That is, DCGs as a notation aren't naturally used as a summarization which hides complexity, but rather to make all the complexity explicit. Conclusion, we need to try using them and see how it works out.

MultiDimensional Arrays
- we reviewed the status of the work on multidimensional arrays.
- we had been assuming we needed more than just 1d array support, but this is now unclear. We've pushed back on "top-down" use of XML Schemas, i.e., DFDL must be used bottom up, and transformation into the "logical form you wanted" is not our job. With respect to multi-dimensional arrays having complex implementations we can adopt the exact same position. The DFDL describes the representation, and the sttructure of the DFDL schema will end up matching the shape of the representation of the array. Transforming that into something that looks and acts like a multi-dimensional array is a transformation that is out-of-scope for us. E.g., if the array is stored as a run-length encoded vector, then it is DFDL's job to describe this run-length encoded vector, but not to project/transform it so that it can be accessed in a manner that hides the run-length encoding and makes it look like an ordinary dense array.
- Mike agreed to write this point up and put it before the WG on our email list.