DFDL inputValueCalc restrictions
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 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States
Daffodil project has been building up an experience document about inputValueCalc, outputValueCalc, and hidden groups. The draft is on our wiki here: *https://s.apache.org/daffodil-experience-with-computed-elements* <https://s.apache.org/daffodil-experience-with-computed-elements> This will get finalized into an OGF Experience document and a number of changes/corrections to the DFDL spec will come out of it I expect. We already have identified that disallowing IVC and OVC on the same element is unnecessary and sometimes you want this. Your case with default values sounds similar. We can incorporate your contribution to the experience document. Take a look and see if the existing discussion can just be enhanced with a sentence about also allowing default on an IVC element. If so I can edit and add it there. 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@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@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
Thanks for the link. I agree with a number of items you have here as being useful. It seems like the best place to put something would be under "Allowing some DFDL properties to Coexist with IVC". The first paragraph could end with: Also, the default property does not conflict and allows the element to not be required during unparse. I've also hit the problem of not having array variables and this seems useful as well as parse-time forward reference. Regards, Bradd Kadlecik z/TPF Development Phone: 1-845-433-1573 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 09/25/2019 12:06 PM Subject: [EXTERNAL] Re: [DFDL-WG] DFDL inputValueCalc restrictions Daffodil project has been building up an experience document about inputValueCalc, outputValueCalc, and hidden groups. The draft is on our wiki here: https://s.apache.org/daffodil-experience-with-computed-elements This will get finalized into an OGF Experience document and a number of changes/corrections to the DFDL spec will come out of it I expect. We already have identified that disallowing IVC and OVC on the same element is unnecessary and sometimes you want this. Your case with default values sounds similar. We can incorporate your contribution to the experience document. Take a look and see if the existing discussion can just be enhanced with a sentence about also allowing default on an IVC element. If so I can edit and add it there. 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 On Wed, Sep 25, 2019 at 11:49 AM Bradd Kadlecik <braddk@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 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
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@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@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
The problem has more to do with "myIVC" not being required. If a default is not permitted then "myIVC" is required during unparse. Regards, Bradd Kadlecik z/TPF Development Phone: 1-845-433-1573 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 10/16/2019 04:50 PM Subject: [EXTERNAL] Re: [DFDL-WG] DFDL inputValueCalc restrictions 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 On Wed, Sep 25, 2019 at 11:49 AM Bradd Kadlecik <braddk@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 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
So my albeit clumsy workaround does achieve that. When unparsing the myIVC element doesn't need to be in the infoset. Daffodil, when unparsing, would look at the stream of infoset events, NOT find one for myIVC, (it would find one for something else presumably) and assume the choice has to go to the other branch which is an empty sequence. It would then determine that NOT finding the myOVC element, it would synthesize one, and try to evaluate the OVC to give it a value. Actually, even if it finds myOVC in the infoset it's still going to evaluate the OVC calculation and overwrite the value. So this may be "a" solution, albeit not necessarily the most desirable one. 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, Oct 16, 2019 at 4:55 PM Bradd Kadlecik <braddk@us.ibm.com> wrote:
The problem has more to do with "myIVC" not being required. If a default is not permitted then "myIVC" is required during unparse.
Regards,
*Bradd Kadlecik* z/TPF Development ------------------------------ *Phone:* 1-845-433-1573 *E-mail:* *braddk@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
[image: Inactive hide details for Mike Beckerle ---10/16/2019 04:50:58 PM---So you are suggesting this: <element name="myOVC" t]Mike Beckerle ---10/16/2019 04:50:58 PM---So you are suggesting this: <element name="myOVC" type="xs:int" dfdl:outputValueCalc="{
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 10/16/2019 04:50 PM Subject: [EXTERNAL] Re: [DFDL-WG] DFDL inputValueCalc restrictions
------------------------------
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* <http://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@us.ibm.com* <braddk@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@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list *dfdl-wg@ogf.org* <dfdl-wg@ogf.org> *https://www.ogf.org/mailman/listinfo/dfdl-wg* <https://www.ogf.org/mailman/listinfo/dfdl-wg>
Yes that is correct. Regards, Bradd Kadlecik z/TPF Development Phone: 1-845-433-1573 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 10/16/2019 05:54 PM Subject: [EXTERNAL] Re: [DFDL-WG] DFDL inputValueCalc restrictions So my albeit clumsy workaround does achieve that. When unparsing the myIVC element doesn't need to be in the infoset. Daffodil, when unparsing, would look at the stream of infoset events, NOT find one for myIVC, (it would find one for something else presumably) and assume the choice has to go to the other branch which is an empty sequence. It would then determine that NOT finding the myOVC element, it would synthesize one, and try to evaluate the OVC to give it a value. Actually, even if it finds myOVC in the infoset it's still going to evaluate the OVC calculation and overwrite the value. So this may be "a" solution, albeit not necessarily the most desirable one. 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 On Wed, Oct 16, 2019 at 4:55 PM Bradd Kadlecik <braddk@us.ibm.com> wrote: The problem has more to do with "myIVC" not being required. If a default is not permitted then "myIVC" is required during unparse. Regards, Bradd Kadlecik z/TPF Development Phone: 1-845-433-1573 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States Inactive hide details for Mike Beckerle ---10/16/2019 04:50:58 PM---So you are suggesting this: <element name="myOVC" tMike Beckerle ---10/16/2019 04:50:58 PM---So you are suggesting this: <element name="myOVC" type="xs:int" dfdl:outputValueCalc="{ From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 10/16/2019 04:50 PM Subject: [EXTERNAL] Re: [DFDL-WG] DFDL inputValueCalc restrictions 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 On Wed, Sep 25, 2019 at 11:49 AM Bradd Kadlecik <braddk@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 2455 South Rd E-mail: braddk@us.ibm.com Poughkeepsie, NY 12601-5400 United States -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
participants (2)
-
Bradd Kadlecik -
Mike Beckerle