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

Suman Kalia kalia at ca.ibm.com
Wed Sep 12 12:20:58 EDT 2012


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 at ca.ibm.com

For info on Message broker
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.html





From:   Steve Hanson <smh at uk.ibm.com>
To:     Mike Beckerle <mbeckerle.dfdl at gmail.com>, 
Cc:     Mark Frost <FROSTMAR at uk.ibm.com>, dfdl-wg at 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 at 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 at uk.ibm.com
tel:+44-1962-815848 



From:        Mike Beckerle <mbeckerle.dfdl at gmail.com> 
To:        Tim Kimber/UK/IBM at IBMGB 
Cc:        dfdl-wg at 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 at 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 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
--
 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20120912/72217299/attachment.html>


More information about the dfdl-wg mailing list