On our call today we were discussing whether a NaN is allowed in the Infoset or not. I found that XML Schema allows NaN as a value, hence, the PSVI allows NaN as a value. I also found that XPath 2.0 specifically says that any operation involving NaN produces another NaN. So, I believe we should allow NaNs in the DFDL Infoset without causing any error. An implementation note, and probably the source of my confusion on this issue is this: I have observed that java's text number parser, if setup and used to create a float or double, and given some gibberish data that I used, produces a java NaN. In this case, a DFDL implementation must not just accept this NaN into the DFDL infoset, but must scrutinize the data to see if it matches the required representation for a NaN based on the DFDL property dfdl:textStandardNaNRep (as well as dfdl:textNumberJustification since the NaN rep may be surrounded by pad characters). If not, then it is a parse error, as the data is not convertible to the type. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com