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.