[dfdl-wg] More documents

[Robert E. McGrath]

Comments on 2 of Mike's comments (in the document he sent Friday).

MJB 1
> I don't see how this proposal can enable creation of "arrays" as an 
> extension. We had previously put off multi-dimensional arrays by suggesting 
> they might fall out of the extensions proposal, but I can't see how to do 
> that from this proposal.
> 
> That's ok. Maybe arrays don't fall out of the extensibility stuff.
> 
> On the other hand, maybe somebody already has an idea for how they could 
> but it just isn't explained here.

I think this is a foundation to build on.

IMO, there are 2 problems to be addressed for Arrays:
  1) what XML structure should be used
  2) how to get data from a variety of stored representations

I think we want to let the user do whatever they want for #1.

For #2, I think we can use a stack of conversions.  Perhaps the
"bottom" would be a big BLOB, or 1D array of elements, with another
layer that defines which of the elements/bytes are element (x, y, z).

I _think_ this could work, but I reserve the right to be wrong when
someone tells me why this can't work!


MJB6 (WRT a guard XPATH, p. 6)
> I'm a bit dissatisfied with this. For realistic conversions I foresee that 
> these predicates are going to be gargantuan sets of things that are 
> combinations of presence or absence of all sorts of rep-property settings, 
> including tests on whether the property's value is literal or is itself a 
> run-time-value. E.g., bytes to Int for binary representations needs to know 
> that the rep-type is binary and that byteOrder is specified to have a value. 
> 
> I'd prefer that each conversion can have a black-box predicate which can 
> examine the current static context. 

Sure, I'd like to see the option for either WB or BB computations for
these guards.  Since XML is essentially unreadable to me, I haven't been
concerned by constructs that might be realy, really, unreadable.