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.