This is section by section review I've receieved about version 017 from
Steve, Geoff and Alan Powell (IBM), concentrating on the semantics
sections (11, 12, 18).
10.1. Table missing simple type definition. (Also, complex type should be
"definition" not "declaration" in schema speak).
11.4. Confusion around the description of the Root Value Approximation.
Not 100% clear what this is trying to convey. Can it be described as being
the equivalent of a DOM tree, built up as we parse our way through the
bits? Also, could the description be moved into its own 11.x section?
11.4.2. Question the use of "memory" as the name for the variables tuple
values - sounded too implementation like.
11.4.2. Why is it necessary to return memory as an output value and pass
the memory separately from the context? Put another way, can we treat
variables the same as other properties?
11.4.3.1. content length - should be end minus start
11.4.3.1. Does the last sentence just mean to refer to non-dimensioned,
non-optional elements?
11.4.3.2. "Dynamic extent" & "dynamic scope" - names not intuitive -
should "representation" be in their somewhere? Also "scope" being re-used
?
12. Format nit: Numbered lists not resetting.
12.3. Ruling out recursion for DFDL v1.0 is probably ok
12.4.1. Needs to handle the case where a sequence/choice is embedded in
another sequence/choice. Terminology assumes that FIRST, MIDDLE, LAST are
elements.
12.4.1. General point: Needs re-inforcing that the content related
operations (FIRST, MIDDLE, LAST, CONTENT) involve recursive calls to P
(specifically one of E, C, G, R).
12.4.2. To be capable of use on a complex type's sequence or on an
embedded sequence, your source to source transform actually replaces an
unordered sequence with an ordered sequence, which contains an array
element of local complex type, whose content is a choice...
12.4.2. "The dfdl:unordered is dropped" ... add "from the transformed
sequence, other DFDL properties are unchanged".
12.4.2. The key sentence in this is "Ordered and unordered are
characteristics of the representation only". This needs to be right up
front.
12.4.2. Concern that implementing our own interpretation of unordered as
described may be seen by wider community as clashing with xsd:all (which
has been relaxed in XSD 1.1), does not allow a user to preserve his
bitstream order (which although random could still have a semantic), and
does not allow us to output exactly what we parsed.
12.4.2. General point: Output matching model order. Needs discussion. If
we consider schema validation as separate from DFDL parse/unparse, then
shouldn't the DFDL unparser output what it is presented with?
12.5. First mention of ATTEMPT. Did you mean EXISTS?
12.6. Why is it necessary to pull EXISTS into the array parser? You don't
do the same for the sequence parser.
12.6. Is a NONE function also needed for sequence? If not can you say why.
12.6. Example call sequence - SEP missing between MIDDLE and EXISTS.
12.7. Is E missing from the first sentence?
12.8. Update to handle embedded sequences/choices.
12.8.1. Format nit: First line - blank space after dfdl:choice.
12.8.1. PRE and POST are handled in MRM today with choices.
12.8.2. Unrelated to main review: dfdl:lengthKind="xpath" .... is a better
enum for this "pathExpression"
12.9.1. xsd:any can take minOccurs and maxOccurs, and default to (1,1). I
think you've assumed that it is (0, unbounded). I think we need to decide
if we support repeating wildcards. If we don't then the source transform
of xsd:any for strict is direct to xsd:choice and for lax is direct to the
xsd:sequence (you don't need the dummy complex type. In both cases you
don't need the extra element, nor therefore the "id" attribute.
12.11.2.2. Would the complexType be better called bytesToBinaryInteger to
match the output repType?
18.1.2. Why is localTerminator a separate argument, isn't everything you
need in the context?
18.1.3. Contradicts itself about use of escape schemes.
18.2. Might not be understanding this. The magic 8 and 16 seem to be
supplying defaults - but we don't allow property defaults.
18.2. binaryPrefixedString, binaryFixedString: DFDL allows lengthUnits to
be 'bytes' for fixed length strings and prefixed strings.
18.2. binaryPrefixedString: LEN calculation omits some of the required
properties
18.2. Not clear what the schema fragment is illustrating, nor the
following P() function and two return statements.
18.4. Can AP and LSB never be set from variables ? They don't take them as
input.
18.4.2. We are not convinced that using the bootstrapping technique of
defining DFDL behaviour in terms of itself always helps. AP is a good
example of things appearing to get overly complicated. It might be
preferable to use some other code or pseudo-code mechanism to specify
these behaviours - like you have in 18.4.3.
