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