[
https://issues.apache.org/jira/browse/DAFFODIL-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820217#comment-17820217
]
Mike Beckerle commented on DAFFODIL-2877:
-----------------------------------------
So the pattern in this case is acting on the logical digits of the number,
i.e., the infoset value, not the representation of the data. E.g., binary
numbers could have pattern facets, pattern facets would not be able to do
things like match leading zeros,.. . as there are no leading zeros on logical
values.
This is a problem because in regular XML Schema facets can apply to the data as
a string, and as a number. I.e., an xs:int can be required by a pattern to have
leading zeros, but also can have maxInclusive/minInclusive facets. All types in
XML are both string and whatever their actual type is. That is not true in
DFDL.
This starts to become problematic if you have data like "10" but type xs:float
and a pattern facet. Because logically that "10" is "10.0E0" in the canonical
XML representation, and there are also NaN and infinity representations.
Another example: "02/01/1961" becomes logically: 1861-02-01 as a logical date.
But are users really going to realize the pattern facet they are writing is not
about the MM/DD/yyyy notation, but the ISO YYYY-MM-DD notation?
I think the right solution to this problem is schematron rules, or XML Schema
1.1 rules (which are similar) which could express the intended behavior without
converting things into ad-hoc and very complex regex patterns, and without the
complexity of an inputValueCalc extra element just to support regex validation.
> Allow pattern restriction facet to be used on non-string types
> --------------------------------------------------------------
>
> Key: DAFFODIL-2877
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2877
> Project: Daffodil
> Issue Type: New Feature
> Components: Back End, Front End
> Reporter: Steve Lawrence
> Priority: Major
>
> Section 5.2 of the DFDL specification says that the pattern restriction facet
> can only be used for xs:string types. Daffodil currently implements this
> limitation.
> However, there are a number of cases where a pattern is the only way to
> correctly restrict the value of non-string types, such as xs:long.
> One example is a number that can only be between 100 and 300 but in multiples
> of 5. In that case, a pattern like this would work:
> {code}
> <xs:pattern value="([12][0-9][05])|([300])" />
> {code}
> Another example could be apartment rooms, where the first digit represents
> the floor (e.g. 1-5), and the second two digits represent the room number
> between 1 and 15 (assuming 15 rooms per floor). In that case, the pattern
> restriction might be:
> {code}
> <xs:pattern value="[1-5]((0[1-9])|(1[0-5]))" />
> {code}
> The patterns are often going to be a bit ugly, but in some cases it's the
> only way to correctly validate numbers using only XML Schema capabilities.
> Note that only supporting pattern on xs:string types is a limitation imposed
> by DFDL--XML schema allows pattern restriction on all types. We should remove
> this limitation and allow pattern facet to be used on all types.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
