[DFDL-WG] DFDL variables as path steps and with predicates

[Mike Beckerle]

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 at 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 at uk.ibm.com
> Tel. 01962-816742
> Internal tel. 37246742
>
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        dfdl-wg at ogf.org,
> Date:        11/09/2012 17:10
> Subject:        [DFDL-WG] DFDL variables as path steps and with predicates
> Sent by:        dfdl-wg-bounces at 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 at 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 at ogf.org
>   https://www.ogf.org/mailman/listinfo/dfdl-wg
>



-- 
Mike Beckerle | OGF DFDL WG Co-Chair
Tel:  781-330-0412
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120912/77bf6ed4/attachment.html>