Agree. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM@IBMGB To: dfdl-wg@ogf.org, Date: 19/06/2013 20:12 Subject: Re: [DFDL-WG] clarification needed: Ignore case Sent by: dfdl-wg-bounces@ogf.org I agree with your thoughts on this. We have taken care not to change the rules of XSD validation when specifying DFDL. So the ignoreCase property controls how we parse the data format, not the logical values in the DFDL info set. I do agree, though, that it is worth making that clear. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 19/06/2013 19:42 Subject: [DFDL-WG] clarification needed: Ignore case Sent by: dfdl-wg-bounces@ogf.org The ignoreCase property description says this: Whether mixed case data is accepted when matching delimiters and data values on input. This affects the behavior of matching for these properties: initiator, terminator, separator, nilValue, textStandardExponentRep, textStandardInfinityRep, textStandardNaNRep, textStandardZeroRep, textBooleanTrue, textBooleanFalse, Ignoring that dangling comma at the end, the question is about what this leaves out, and making sure this is intentional. 1. If an element of type string has the XSD attribute fixed="...." with some value, is that comparison of the fixed value to the data content guided by dfdl:ignoreCase? 2. If an element of simple type string has enumerations, are the comparisons of the enum values to what is found in the data guided by dfdl:ignoreCase? My thought is No and No, as these are purely XSD issues, not DFDL related, so we want our behavior to be exactly the same as XSD here. The XSD/XML world is simply a very case-sensitive one. This page (http://www.ibm.com/developerworks/library/x-case/) is about a user asking how to do case-insensitive enum comparisons in XSD. The hack workaround is changing to use a pattern/regex match. I.e., instead of case insensitive "red" you get a pattern match of "[r|R][e|E][d|D]" which is blechy, but effective. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU