[DFDL-WG] DFDL inputValueCalc restrictions

Mike Beckerle mbeckerle.dfdl at gmail.com
Wed Oct 16 16:48:59 EDT 2019


So you are suggesting this:

        <element name="myOVC" type="xs:int" dfdl:outputValueCalc="{
../myIVC + 3 }" />
        <element name="myIVC" type="xs:int" dfdl:inputValueCalc="{ compute
here }" default="0"/><!-- default only used when unparsing -->

That's not unreasonable.

Question: Can the behavior you need be represented by way of a test for
existence of the IVC element?

<element name="myOVC" type="xs:int" dfdl:outputValueCalc="{ if
(fn:not(fn:exists(../myIVC))) then 0 else ....do the real computation
here.... }"/>
<!-- an optional IVC element -->
<choice>
    <sequence> <!-- IVC can't be root of a choice branch so workaround -->
        <element name="myIVC" dfdl:inputValueCalc="{ compute here }"/>
    </sequence>
    <sequence/> <!-- nothing at all is the other alternative -->
</choice>

That's clumsier, but does achieve, I think, the same behavior without
depending on defaulting. It does depend on fn:exists and fn:not functions.


Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>



On Wed, Sep 25, 2019 at 11:49 AM Bradd Kadlecik <braddk at us.ibm.com> wrote:

> Hello,
>
> I have one item I'd like to discuss at some point regarding inputValueCalc
> and not allowing the default property to be specified. I have a use case
> where the default property would be useful for unparse. It makes perfect
> sense to not allow it for outputValueCalc however.
>
> The use case is in forming a connection between an inputValueCalc element
> and an outputValueCalc element where the incoming document might not
> contain the inputValueCalc element for unparse and a default value would be
> desired for the outputValueCalc use. This is an item our customers using
> DFDL would like to make use of but don't want to require the element to
> always exist for unparse.
>
> Regards,
>
> *Bradd Kadlecik*
> z/TPF Development
> ------------------------------
> *Phone:* 1-845-433-1573
> *E-mail:* *braddk at us.ibm.com* <braddk at us.ibm.com>
> 2455 South Rd
> Poughkeepsie, NY 12601-5400
> United States
>
>
> --
>   dfdl-wg mailing list
>   dfdl-wg at ogf.org
>   https://www.ogf.org/mailman/listinfo/dfdl-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20191016/2195899f/attachment.html>


More information about the dfdl-wg mailing list