DFDL variables as path steps and with predicates
Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | *VarRef* | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412
Interesting...I naturally interpreted $x/a/b/$y/../$z as a series of macro-expansions of the stringified values of the variables $x, $y and $z. You clearly assumed something different - that $x is a complex-valued object with a child called 'a'. I cannot see much value for DFDL in either interpretation, to be honest. If a path reference can contain variables then it will not always be possible to work out which parts of the schema will participate in expression evaluation. The example usage that you gave { fn:exists($x[. eq 3] } could be replaced by { $x eq 3] }. Are there any other usages that could only be done using a variable in a path ref? My proposal would be to allow var refs within the predicate expression of a StepExpr but not anywhere else in a StepExpr. Integer variables could then be used to calculate an array position in a predicate. This would require only a small change to the grammar, and I think it was probably the intention when this was originally put into the specification. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 11/09/2012 17:10 Subject: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | VarRef | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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
That notion, that a variable could contain "a", and that could be used in a path so that .../$x/... would mean to descend to child 'a' at that point, looks to me that it goes beyond what XPath 2.0 allows. I'm not an XPath expert, but XPath 2.0 is strong-typecheck-capable, and that requires the path-steps in it, each of which can cause the type to change, to be statically apparent in the expressions. A really dynamic path can only have the vacuous type Any. You could of course construct a string that is such a path first, and then as XPath 2.0 to evaluate it, but that requires work outside the expression. But I totally agree with you that there's no value to DFDL, and no need for anything other than where a variable like $x provides a single node value of simple type, and can be used exactly and only where such a value would be meaningful. So I think $x should appear alone as a value-producing expression, including, as you pointed out things like a[$x] should work because $x could be an integer value. ...mikeb On Tue, Sep 11, 2012 at 6:54 PM, Tim Kimber <KIMBERT@uk.ibm.com> wrote:
Interesting...I naturally interpreted $x/a/b/$y/../$z as a series of macro-expansions of the stringified values of the variables $x, $y and $z. You clearly assumed something different - that $x is a complex-valued object with a child called 'a'.
I cannot see much value for DFDL in either interpretation, to be honest. If a path reference can contain variables then it will not always be possible to work out which parts of the schema will participate in expression evaluation. The example usage that you gave { fn:exists($x[. eq 3] } could be replaced by { $x eq 3] }. Are there any other usages that could only be done using a variable in a path ref?
My proposal would be to allow var refs within the predicate expression of a StepExpr but not anywhere else in a StepExpr. Integer variables could then be used to calculate an array position in a predicate. This would require only a small change to the grammar, and I think it was probably the intention when this was originally put into the specification.
regards,
Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 11/09/2012 17:10 Subject: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org ------------------------------
Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear:
PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | *VarRef* | ParenthesizedExp
in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z.
However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless.
But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes.
For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3.
Are there any issues here with predicates??
Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax.
If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value.
...mikeb
-- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
-- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412
The reason that a DFDL variable appears to be allowed in a path is because XPath 2.0 allows it. Specifically, XPath 2.0 allows: $var/aaa/bbb Here $var has to return a node. It can't return an atomic value. It's a nice feature as it allows what I would describe as dynamic absolute paths. In DFDL though all expressions must return an atomic value so we can't exploit this. XPath 2.0 does not allow $var/aaa/bb or aaa/$var/bbb where $var is an atomic value. Hence DFDL can not allow this. I think an errata is needed to the DFDL EBNF to remove the possibility of a variable appearing in a path other than as a predicate. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Tim Kimber/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org Date: 12/09/2012 14:48 Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org That notion, that a variable could contain "a", and that could be used in a path so that .../$x/... would mean to descend to child 'a' at that point, looks to me that it goes beyond what XPath 2.0 allows. I'm not an XPath expert, but XPath 2.0 is strong-typecheck-capable, and that requires the path-steps in it, each of which can cause the type to change, to be statically apparent in the expressions. A really dynamic path can only have the vacuous type Any. You could of course construct a string that is such a path first, and then as XPath 2.0 to evaluate it, but that requires work outside the expression. But I totally agree with you that there's no value to DFDL, and no need for anything other than where a variable like $x provides a single node value of simple type, and can be used exactly and only where such a value would be meaningful. So I think $x should appear alone as a value-producing expression, including, as you pointed out things like a[$x] should work because $x could be an integer value. ...mikeb On Tue, Sep 11, 2012 at 6:54 PM, Tim Kimber <KIMBERT@uk.ibm.com> wrote: Interesting...I naturally interpreted $x/a/b/$y/../$z as a series of macro-expansions of the stringified values of the variables $x, $y and $z. You clearly assumed something different - that $x is a complex-valued object with a child called 'a'. I cannot see much value for DFDL in either interpretation, to be honest. If a path reference can contain variables then it will not always be possible to work out which parts of the schema will participate in expression evaluation. The example usage that you gave { fn:exists($x[. eq 3] } could be replaced by { $x eq 3] }. Are there any other usages that could only be done using a variable in a path ref? My proposal would be to allow var refs within the predicate expression of a StepExpr but not anywhere else in a StepExpr. Integer variables could then be used to calculate an array position in a predicate. This would require only a small change to the grammar, and I think it was probably the intention when this was originally put into the specification. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 11/09/2012 17:10 Subject: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | VarRef | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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
How about the expression -> aaa/$var $var returning an atomic value would be perfectly valid.. Are we going to allow this ? Suman Kalia IBM Canada Lab WMB Toolkit Architect and Development Lead Tel: 905-413-3923 T/L 313-3923 Email: kalia@ca.ibm.com For info on Message broker http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.ht... From: Steve Hanson <smh@uk.ibm.com> To: Mike Beckerle <mbeckerle.dfdl@gmail.com>, Cc: Mark Frost <FROSTMAR@uk.ibm.com>, dfdl-wg@ogf.org Date: 09/12/2012 11:47 AM Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org The reason that a DFDL variable appears to be allowed in a path is because XPath 2.0 allows it. Specifically, XPath 2.0 allows: $var/aaa/bbb Here $var has to return a node. It can't return an atomic value. It's a nice feature as it allows what I would describe as dynamic absolute paths. In DFDL though all expressions must return an atomic value so we can't exploit this. XPath 2.0 does not allow $var/aaa/bb or aaa/$var/bbb where $var is an atomic value. Hence DFDL can not allow this. I think an errata is needed to the DFDL EBNF to remove the possibility of a variable appearing in a path other than as a predicate. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Tim Kimber/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org Date: 12/09/2012 14:48 Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org That notion, that a variable could contain "a", and that could be used in a path so that .../$x/... would mean to descend to child 'a' at that point, looks to me that it goes beyond what XPath 2.0 allows. I'm not an XPath expert, but XPath 2.0 is strong-typecheck-capable, and that requires the path-steps in it, each of which can cause the type to change, to be statically apparent in the expressions. A really dynamic path can only have the vacuous type Any. You could of course construct a string that is such a path first, and then as XPath 2.0 to evaluate it, but that requires work outside the expression. But I totally agree with you that there's no value to DFDL, and no need for anything other than where a variable like $x provides a single node value of simple type, and can be used exactly and only where such a value would be meaningful. So I think $x should appear alone as a value-producing expression, including, as you pointed out things like a[$x] should work because $x could be an integer value. ...mikeb On Tue, Sep 11, 2012 at 6:54 PM, Tim Kimber <KIMBERT@uk.ibm.com> wrote: Interesting...I naturally interpreted $x/a/b/$y/../$z as a series of macro-expansions of the stringified values of the variables $x, $y and $z. You clearly assumed something different - that $x is a complex-valued object with a child called 'a'. I cannot see much value for DFDL in either interpretation, to be honest. If a path reference can contain variables then it will not always be possible to work out which parts of the schema will participate in expression evaluation. The example usage that you gave { fn:exists($x[. eq 3] } could be replaced by { $x eq 3] }. Are there any other usages that could only be done using a variable in a path ref? My proposal would be to allow var refs within the predicate expression of a StepExpr but not anywhere else in a StepExpr. Integer variables could then be used to calculate an array position in a predicate. This would require only a small change to the grammar, and I think it was probably the intention when this was originally put into the specification. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 11/09/2012 17:10 Subject: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | VarRef | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
As I said below, XPath 2.0 does not allow atomic values to appear in paths. So DFDL will not do so either. Each non-initial occurrence of "//" in a path expression is expanded as described in 3.2.4 Abbreviated Syntax, leaving a sequence of steps separated by "/". This sequence of steps is then evaluated from left to right. Each operation E1/E2 is evaluated as follows: Expression E1 is evaluated, and if the result is not a (possibly empty) sequence of nodes, a type error is raised [err:XPTY0019]. Each node resulting from the evaluation of E1 then serves in turn to provide an inner focus for an evaluation of E2, as described in 2.1.2 Dynamic Context. The sequences resulting from all the evaluations of E2 are combined as follows: If every evaluation of E2 returns a (possibly empty) sequence of nodes, these sequences are combined, and duplicate nodes are eliminated based on node identity. The resulting node sequence is returned in document order. If every evaluation of E2 returns a (possibly empty) sequence of atomic values, these sequences are concatenated, in order, and returned. If the multiple evaluations of E2 return at least one node and at least one atomic value, a type error is raised [err:XPTY0018]. Andy C tried it out with XLTXE - he got back the error message. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Suman Kalia <kalia@ca.ibm.com> To: Steve Hanson/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org, Mark Frost/UK/IBM@IBMGB, Mike Beckerle <mbeckerle.dfdl@gmail.com> Date: 12/09/2012 17:21 Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates How about the expression -> aaa/$var $var returning an atomic value would be perfectly valid.. Are we going to allow this ? Suman Kalia IBM Canada Lab WMB Toolkit Architect and Development Lead Tel: 905-413-3923 T/L 313-3923 Email: kalia@ca.ibm.com For info on Message broker http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.ht... From: Steve Hanson <smh@uk.ibm.com> To: Mike Beckerle <mbeckerle.dfdl@gmail.com>, Cc: Mark Frost <FROSTMAR@uk.ibm.com>, dfdl-wg@ogf.org Date: 09/12/2012 11:47 AM Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org The reason that a DFDL variable appears to be allowed in a path is because XPath 2.0 allows it. Specifically, XPath 2.0 allows: $var/aaa/bbb Here $var has to return a node. It can't return an atomic value. It's a nice feature as it allows what I would describe as dynamic absolute paths. In DFDL though all expressions must return an atomic value so we can't exploit this. XPath 2.0 does not allow $var/aaa/bb or aaa/$var/bbb where $var is an atomic value. Hence DFDL can not allow this. I think an errata is needed to the DFDL EBNF to remove the possibility of a variable appearing in a path other than as a predicate. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Tim Kimber/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org Date: 12/09/2012 14:48 Subject: Re: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org That notion, that a variable could contain "a", and that could be used in a path so that .../$x/... would mean to descend to child 'a' at that point, looks to me that it goes beyond what XPath 2.0 allows. I'm not an XPath expert, but XPath 2.0 is strong-typecheck-capable, and that requires the path-steps in it, each of which can cause the type to change, to be statically apparent in the expressions. A really dynamic path can only have the vacuous type Any. You could of course construct a string that is such a path first, and then as XPath 2.0 to evaluate it, but that requires work outside the expression. But I totally agree with you that there's no value to DFDL, and no need for anything other than where a variable like $x provides a single node value of simple type, and can be used exactly and only where such a value would be meaningful. So I think $x should appear alone as a value-producing expression, including, as you pointed out things like a[$x] should work because $x could be an integer value. ...mikeb On Tue, Sep 11, 2012 at 6:54 PM, Tim Kimber <KIMBERT@uk.ibm.com> wrote: Interesting...I naturally interpreted $x/a/b/$y/../$z as a series of macro-expansions of the stringified values of the variables $x, $y and $z. You clearly assumed something different - that $x is a complex-valued object with a child called 'a'. I cannot see much value for DFDL in either interpretation, to be honest. If a path reference can contain variables then it will not always be possible to work out which parts of the schema will participate in expression evaluation. The example usage that you gave { fn:exists($x[. eq 3] } could be replaced by { $x eq 3] }. Are there any other usages that could only be done using a variable in a path ref? My proposal would be to allow var refs within the predicate expression of a StepExpr but not anywhere else in a StepExpr. Integer variables could then be used to calculate an array position in a predicate. This would require only a small change to the grammar, and I think it was probably the intention when this was originally put into the specification. regards, Tim Kimber, DFDL Team, Hursley, UK Internet: kimbert@uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 11/09/2012 17:10 Subject: [DFDL-WG] DFDL variables as path steps and with predicates Sent by: dfdl-wg-bounces@ogf.org Currently the DFDL spec's grammar productions are quite liberal about where a VarRef can appear: PathExpr ::= ("/" RelativePathExpr?) | RelativePathExpr RelativePathExpr ::= StepExpr (("/") StepExpr)* StepExpr ::= FilterExpr | AxisStep AxisStep ::= (ReverseStep | ForwardStep) Predicate FilterExpr ::= PrimaryExpr Predicate Predicate ::= "[" Expr "]" PrimaryExpr ::= Literal | VarRef | ParenthesizedExp in terms of XPath 2.0 syntax, you could write $x/a/b/$y/../$z. However, the spec also says the type of a variable can only be one of the simple types allowed by DFDL only. So no path steps in the sense of children are meaningful after a DFDL variable. Furthermore, variables are all declared at top level. There is no notion of parent nodes for variable values; hence, a/$x is meaningless (or means the same as $x by itself), and $x/.. is similarly meaningless. But, a variable reference can be followed by a predicate. The resulting node set, would either be one node, containing the value of the variable, or zero nodes. For example is { fn:exists($x[. eq 3] } is presumably a boolean valued expression true if variable x's value is 3. Are there any issues here with predicates?? Should we update the expression language productions to enable only sensible use of DFDL variables in expressions or leave it to match XPath 2.0's more general syntax. If we update the productions should we disallow predicates after variable references also? This loses no expressive power, you can still write { if ($x eq 3) then true else false }, which is to say I think there is no inherent capability lost if we require variable references to be atomic expressions that produce exactly a single node value. ...mikeb -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412 -- 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 -- 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 (4)
-
Mike Beckerle -
Steve Hanson -
Suman Kalia -
Tim Kimber