[
https://issues.apache.org/jira/browse/DAFFODIL-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155670#comment-17155670
]
Mike Beckerle edited comment on DAFFODIL-2350 at 7/30/20, 7:02 PM:
-------------------------------------------------------------------
Also should allow other XSD validations. E.g., pattern facets on hexBinary
data. This is allowed by XML schema, but disallowed by DFDL.
But it is very handy if DFDL is used to convert data into XML, to have
arbitrary XML schema validations run against the XML.
This is disallowed because DFDL itself can't execute them. DFDL itself isn't
actually converting anything into hex characters so a pattern that operates as
if hexBinary was a string won't work in DFDL and isn't meaningful.
Nevertheless we want to create schemas that are both DFDL schemas, and also can
be used to validate data AFTER it's been converted into XML.
As an example, suppose you have data that is supposed to be padded at the end
with zero bytes, to some fixed length. The data wants to be well-formed
(parsed) regardless of what bytes are in the padding, but wants to be invalid
XML once it has been converted to XML.
There is no way in DFDL to treat this as hexBinary of some length, and then
somehow require that the bytes are all zero bytes. In plain old XSD, for XML,
this is easy. Use a pattern and check that the hex string is "0*".
was (Author: mbeckerle):
Also should allow other XSD validations. E.g., pattern facets on hexBinary
data. This is allowed by XML schema, but disallowed by DFDL.
But it is very handy if DFDL is used to convert data into XML, to have
arbitrary XML schema validations run against the XML.
This is disallowed because DFDL itself can't execute them. DFDL itself isn't
actually converting anything into hex characters so a pattern that operates as
if hexBinary was a string won't work in DFDL and isn't meaningful.
Nevertheless we want to create schemas that are both DFDL schemas, and also can
be used to validate data AFTER it's been converted into XML.
As an example, suppose you have data that is supposed to be padded at the end
with zero bytes, to some fixed length. The data wants to be well-formed
(parsed) regardless of what bytes are in the padding, but wants to be invalid
XML once it has been converted to XML.
There is no way in DFDL to treat this as hexBinary of some length, and then
somehow require that the bytes are all zero bytes. In plain old XSD, for XML,
this is easy. Use a pattern and check that the hex string is "0*".
If instead you model this padding as a string in iso-8859-1, then these zero
bytes become characters with code-point 0. (NUL) These aren't even
representable in XML, so Daffodil converts them to code point U+E000. Alas, a
pattern facet <xs:pattern value="*"/> doesn't work. Even for data known
to be all E000 characters, the pattern facet doesn't validate.
(Probably a daffodil and/or xerces bug.)
> Allow XSD key and unique constraints in DFDL schemas
> ----------------------------------------------------
>
> Key: DAFFODIL-2350
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2350
> Project: Daffodil
> Issue Type: Bug
> Components: Front End
> Affects Versions: 2.6.0
> Reporter: Mike Beckerle
> Priority: Major
> Fix For: 3.0.0
>
>
> DFDL uses only a subset of XSD features.
> That subset doesn't include xs:key and xs:unique constraints.
> However, those are very useful for integrity checking once data has be
> converted from native format into XML.
> So Daffodil should simply ignore these xs:key and xs:unique features thereby
> allowing them to be in the DFDL schema when it is used only as an XML schema
> for validation purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
