"dfdlx" means it is an extension to DFDL and likely isn't supported by other
DFDL implementations. Extensions often are used for prototyping new features in
Daffodil and once all the kinks are worked out we propose it to the DFDL working
group for inclusion in a future version of the official spec. So it's possible
these features could become standard.
I wouldn't necessarily call it bad to use extensions unless you are trying to
create a portable schema. If you know your schema will only be used with
Daffodil using an extension is fine.
One caveat is since extensions are sort of prototypes for eventual DFDL
inclusion, they sometimes need changes, so there is the potential for backwards
compatibility issues with different versions of Daffodil. But that's fairly rare
and usually the changes are just removing parts of an extension that aren't
used. The dfdlx:repType extension is heavily used so I don't expect it to change.
On 2024-05-29 07:44 AM, Roger L Costello wrote:
Thanks Steve!
dfdlx:repType ßI assume ‘x’ means ‘extension’, right? I.e., not standard DFDL,
right? Not standard equals ‘bad’, right?
*From:*Steve Lawrence <slawre...@apache.org>
*Sent:* Wednesday, May 29, 2024 7:40 AM
*To:* users@daffodil.apache.org
*Subject:* [EXT] Re: Does Daffodil support the XPath "to" operator?
That is correct, daffodil dost not support the "to" operator. However, DFDL
defines, and Daffodil supports as of 3. 7. 0, the dfdl: checkRangeInclusive and
dfdl: checkRangeExclusive functions, for example, you could use this instead: if
(dfdl: checkRangeInclusive(. . /BitCode,
ZjQcmQRYFpfptBannerStart
erEnd
That is correct, daffodil dost not support the "to" operator.
However, DFDL defines, and Daffodil supports as of 3.7.0, the
dfdl:checkRangeInclusive and dfdl:checkRangeExclusive functions, for example,
you could use this instead:
if (dfdl:checkRangeInclusive(../BitCode, 12, 71)) then 'UNDEFINED'
Alternatively, you might consider using repType/enuemration/repValues, which was
designed to replace these complex inputValueCalcs that are essentially just enum
lookup tables. For example, your BitCode/Meaning elements would be replaced with
this:
<element name="BitCode" dfdlx:repType="unsignedInt5">
<simpleType>
<restriction base="xs:string">
<enumeration value="A" dfdlx:repValues="0" />
<enumeration value="B" dfdlx:repValues="1" />
...
<enumeration value="UNDEFINED" dfdlx:repValueRanges="12 71" />
</restriction>
</simpleType>
</element>
So BitCode is now an xs:string and only the string value appears in the infoset.
But we first parse it as an unsignedInt5 because of the repType, then look up
the matching repValue in the enumeration to find the string value. So if we
parse a 1, BitCode gets a value of "B" in the infoset. If it's in the range of
12 to 71 inclusive then the infoset gets "UNDEFINED".
On 2024-05-29 07:24 AM, Roger L Costello wrote:
In an inputValueCalc I want to have this:
if (../BitCode = (12 to 71)) then 'UNDEFINED'
See below. From my testing, it appears that Daffodil does not support the "to"
operator. Is that correct? Is there a workaround?
<xs:element name="test">
<xs:complexType>
<xs:sequence>
<xs:element name="BitCode" type="unsignedint5"/>
<xs:element name="Meaning" type="xs:string"
dfdl:inputValueCalc="{
if (../BitCode eq 0) then 'A'
else if (../BitCode eq 1) then 'B'
...
else if (../BitCode = (12 to 71)) then 'UNDEFINED'
else fn:error('invalid value for test')
}"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
