clarification needed: conversions to required type of expressions - implicit or explicit
We have a test for Daffodil that does this: <element name="y" type="xsd:boolean" maxOccurs="unbounded" dfdl:textBooleanTrueRep="{ 1*10 }" dfdl:textBooleanFalseRep="{'a b c'}" /> We found that we must change this to: dfdl:textBooleanTrueRep="{ xsd:string(1*10) }" For the test to be portable and work on IBM DFDL as well as Daffodil. So the issue to discuss is, are string conversions, or in general conversions to the required property's type (e.g., integer for dfdl:length), are these implicit, or do they have to be explicit? I didn't find language in the DFDL spec that makes this clear. The properties tend to be clear on what the type needs to be (string or integer typically). The XPath language that is what we derive DFDL's expression language from, has lots of conversion/coercion rules. Everything can be implicitly converted to a string. We say our DFDL expression language is a subset of XPath 2.0, and that we explicitly say we use XPath 2.0's type system and respect its errors, and we say DFDL implementations may use XPath 2.0 implementations if they do some pre-processing. So the clarification is reduced to this: Does an entire DFDL expression for the value of a property behave as if it was an actual argument to a function, that formal argument having the type required by the property? In that case coercions would be inserted to convert say, numbers to strings. Alternatively, does the expression for a property have to explicitly convert to the type that the property requires? 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
These are the relevant bullets from section 23.3: h Every property that accepts an expression states exactly what the expression is expected to return. To ensure the returned value is of the correct type, an expression must use XPath constructors or the correct literal values. h No extra auto-casting is performed over and above that provided by XPath 2.0. XPath 2.0 has rules for when it promotes types and when it allows types to be substituted. These are in Appendix B.1 of the XPath 2.0 spec. Note the use of 'must' in the first bullet. I don't see anywhere in XPath 2.0 spec that covers your auto-casting example. Promoting int to string is not covered by XPath 2.0 spec Appendix B.1 as far as I can see. I think I can recall this being discussed way back, and the conclusion was to always use constructors to make expressions explicit. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: DFDL-WG <dfdl-wg@ogf.org> Date: 20/11/2018 18:22 Subject: [DFDL-WG] clarification needed: conversions to required type of expressions - implicit or explicit Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> We have a test for Daffodil that does this: <element name="y" type="xsd:boolean" maxOccurs="unbounded" dfdl:textBooleanTrueRep="{ 1*10 }" dfdl:textBooleanFalseRep="{'a b c'}" /> We found that we must change this to: dfdl:textBooleanTrueRep="{ xsd:string(1*10) }" For the test to be portable and work on IBM DFDL as well as Daffodil. So the issue to discuss is, are string conversions, or in general conversions to the required property's type (e.g., integer for dfdl:length), are these implicit, or do they have to be explicit? I didn't find language in the DFDL spec that makes this clear. The properties tend to be clear on what the type needs to be (string or integer typically). The XPath language that is what we derive DFDL's expression language from, has lots of conversion/coercion rules. Everything can be implicitly converted to a string. We say our DFDL expression language is a subset of XPath 2.0, and that we explicitly say we use XPath 2.0's type system and respect its errors, and we say DFDL implementations may use XPath 2.0 implementations if they do some pre-processing. So the clarification is reduced to this: Does an entire DFDL expression for the value of a property behave as if it was an actual argument to a function, that formal argument having the type required by the property? In that case coercions would be inserted to convert say, numbers to strings. Alternatively, does the expression for a property have to explicitly convert to the type that the property requires? 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-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
We implemented casting/conversion based on https://www.w3.org/TR/xquery-operators/#casting-from-primitive-to-primitive And I believe these casting/conversions are required for an implementation of the DFDL expression language, for when sub-expressions are composed with each other to form larger expressions. E.g., if you call fn:concat, which takes string arguments, you can pass numbers to it, because they are auto-converted to strings. However, the DFDL spec bullets you cite are pretty clear that this shouldn't be done for the return value of an expression that is providing the value of a property, like the one for dfdl:textBooleanTrueRep="{ 1*10 }" which should cause an SDE/type-error. So this is a daffodil bug. 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 Tue, Nov 20, 2018 at 5:37 PM Steve Hanson <smh@uk.ibm.com> wrote:
These are the relevant bullets from section 23.3:
„h Every property that accepts an expression states exactly what the expression is expected to return. To ensure the returned value is of the correct type, an expression must use XPath constructors or the correct literal values.
„h No extra auto-casting is performed over and above that provided by XPath 2.0. XPath 2.0 has rules for when it promotes types and when it allows types to be substituted. These are in Appendix B.1 of the XPath 2.0 spec.
Note the use of 'must' in the first bullet. I don't see anywhere in XPath 2.0 spec that covers your auto-casting example. Promoting int to string is not covered by XPath 2.0 spec Appendix B.1 as far as I can see.
I think I can recall this being discussed way back, and the conclusion was to always use constructors to make expressions explicit.
Regards
Steve Hanson
IBM Hybrid Integration, Hursley, UK Architect, *IBM DFDL* <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> *smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: DFDL-WG <dfdl-wg@ogf.org> Date: 20/11/2018 18:22 Subject: [DFDL-WG] clarification needed: conversions to required type of expressions - implicit or explicit Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> ------------------------------
We have a test for Daffodil that does this:
<element name="y" type="xsd:boolean" maxOccurs="unbounded" dfdl:textBooleanTrueRep="{ 1*10 }" dfdl:textBooleanFalseRep="{'a b c'}" />
We found that we must change this to:
dfdl:textBooleanTrueRep="{ xsd:string(1*10) }"
For the test to be portable and work on IBM DFDL as well as Daffodil.
So the issue to discuss is, are string conversions, or in general conversions to the required property's type (e.g., integer for dfdl:length), are these implicit, or do they have to be explicit?
I didn't find language in the DFDL spec that makes this clear. The properties tend to be clear on what the type needs to be (string or integer typically).
The XPath language that is what we derive DFDL's expression language from, has lots of conversion/coercion rules. Everything can be implicitly converted to a string.
We say our DFDL expression language is a subset of XPath 2.0, and that we explicitly say we use XPath 2.0's type system and respect its errors, and we say DFDL implementations may use XPath 2.0 implementations if they do some pre-processing.
So the clarification is reduced to this: Does an entire DFDL expression for the value of a property behave as if it was an actual argument to a function, that formal argument having the type required by the property? In that case coercions would be inserted to convert say, numbers to strings.
Alternatively, does the expression for a property have to explicitly convert to the type that the property requires?
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-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
participants (2)
-
Mike Beckerle -
Steve Hanson