Agreed that the statement should be dropped
from the spec. DFDL implementations are free to issue a warning if they
detect such a mismatch (so the IBM DFDL check will change from an error
to a warning).
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
----- Forwarded by Steve
Hanson/UK/IBM on 28/08/2013 16:31 -----
From:
Steve Hanson/UK/IBM
To:
dfdl-wg@ogf.org,
Date:
22/08/2013 16:02
Subject:
Re: [DFDL-WG]
clarification needed: 16.3.1 and totalDigits, fractionDigits and textNumberPattern
compatibility checks
To comply with the spec as stated, the
actual check implemented by IBM DFDL is that the number of fraction/total
digits in the DFDL textNumberPattern must not exceed the number of fraction/total
digits specified by the facet. That's a more liberal interpretation
of 'match' but makes sense.
However the spec does not say that the
textNumberPattern should not be allowed to describe a number greater than
any maxInclusive/maxExclusive facet. And I don't think that there are any
other checks to see that DFDL properties clash with schema facets.
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:
Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:
"dfdl-wg@ogf.org"
<dfdl-wg@ogf.org>,
Cc:
Jessie Chab <jchab@tresys.com>
Date:
22/08/2013 15:35
Subject:
[DFDL-WG] clarification
needed: 16.3.1 and totalDigits, fractionDigits and textNumberPattern compatibility
checks
Sent by:
dfdl-wg-bounces@ogf.org
The spec says that these need to be compatible.
"If the pattern uses digits/fractions then these must match any XML
schema facets."
We've fallen into this trap before. Facet constraints
are about the logical value, not the physical rep, and so must make equal
sense for binary representations as text representations.
I was considering what kinds of static cross checks would
make sense here.
Example: suppose fractionDigits='2'.
Suppose textNumberPattern="##"
the type must be xs:decimal since that's the only type
that can have fractionDigits constrained in DFDL.
Is there a conflict of the facet with the textNumberPattern? I think not.
Even though the pattern doesn't allow for any fractional part to be expressed,
that means that all values will have less than or equal to 2 fractional
digits (because no fractional digits always satisfies that.)
Now suppose textNumberPattern="#.########"
Now the textNumberPattern will parse and accept things like 1.234 which
have more than 2 fraction digits, but suppose the data simply doesn't contain
any such. So all number in the data will obey the less than or equal to
2 fractional digits.
Lastly, suppose textNumberPattern="9.9999"
So, interpreted naively, this requires the data to contain 5 digits, so
this seems inconsistent with fractionDigits of 2.
However, we know this depends on the strict/lax behavior of ICU libraries,
and I believe this will happily parse the data "0.0" without
error. Hence the data could still all have 2 or fewer fractional digits.
So, I think this idea that the totalDigits and fractionDigits facets can
be cross-checked with the textNumberPattern is spurious and we should drop
it.
I think it dates from a time when we were still confused about the separation
of the DFDL Infoset, and facet constraints on its value spaces, which are
abstract, versus the XML Infoset, where everything truly is a string as
well as whatever its XML Schema type says.
Comments?
--
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
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