This arose out of discussion of greedy parse behavior for delimiters, but is clearly distinct from that. I wrote this language as proposed clarification around the issue of greedy parsing for literal nil values. *When nilKind='literalValue' the list of values provided by the nilValue property is processed in a greedy manner, meaning it takes all the strings from the whitespace separated list that is the value of the nilValue property, and sorts them longest first, with length-ties remaining in the same order as written in the schema. (This is sometimes called a stable sort - ties aren't re-ordered.) The processor then attempts to match them against the data stream one by one. Once a match is found, the literal nil representation is said to be found, and no other possibilities for the literal nil representation of that element will be subsequently attempted. (That is, the DFDL processor will not attempt to try any of the other literal nil representations in hopes of obtaining a successful parse, should the selected one lead to a processing error.) Having matched the literal nil representation, the element may still fail to parse as a nil value if the matched literal nilValue is not followed by the appropriate termination as specified by the terminator property and the nilValueDelimiterPolicy property. * I'm not sure this is clear enough, so I offer it as a topic for discussion.