mbeckerle
commented
3 years ago 13.11.1 The dfdl:calendarPatternProperty
The table should distinguish parse behavior (what is accepted) from what is output when unparsing.
For example, is it possible to get any of the day-of-week E patterns to output "TUE" for Tuesday, i.e., all uppercase? For parsing there seems to be no distinction between E, EE, and EEE, but perhaps there is unparser behavior differences?
For Section 9.2.7
Consider inserting another example here of an element which has all 4 representations distinguishable usefully. e.g., nillable with nilValue '-' and NVDP 'none', initiator and terminator with EVDP 'both' and default value a string with two quotation marks. An assertion should insist the value is not the nil nor empty rep so that valid Infoset data will not be ambiguous on unparsing. Absent rep may or may not be a parse error, with a forward reference to the section on separator suppression policy.
For Section 14.2.3.1
Would be good to have a parsing example corresponding to this, i.e., that is legal, and expresses the infoset with trailing nil.
In general more examples are helpful here. The three-pass example may be useful here to drive the point home about canonicalization.