[DFDL-WG] what do we allow in DFDL expressions after "/"

Wed Feb 6 13:13:41 EST 2013

The fact that in StepExpr a FilterExpr is an alternative to AxisStep is the
big problem with this grammar. It allows many things to show up as path
steps that we don't want to allow.

At minimum, we need to change the FilterExpr production to drop Predicate,
as I believe in no context do we allow such a predicate. No-op path steps
like foo/./bar  or ./bar or foo/. are also legal in XPath syntax
technically, but I see no reason for us to allow them, and this is what we
get if we simply state that in DFDL FilterExpr cannot appear inside a
multi-step PathExpr.   If we feel we must allow these, then I would just
add ContextItemExpr as an alternative to NodeTest in  AbbrevForwardStep.

So, we can leave the rest of the productions as is, but with a clarifying
note that FilterExpr in DFDL is limited i.e., that they cannot be used
inside multi-step paths as the grammar would imply. Rather, they must
appear in isolation (no "/" on either side).

However, this grammar structure is very unmotivated in that case,
restructuring the StepExpr and  PathExpr as you have suggested below is a
better choice as far as I am concerned. And we can highlight somehow (I
suggest bold font) the productions or changes to productions that make it
different from the XPath grammar.

So here's the contemplated set of changes:
*
*drop FilterExpr as an alternative
 *StepExpr* * *  ::=  * * *AxisStep*
add FilterExpr as an alternative (or we could just add PrimaryExpr instead)
 *PathExpr*    ::=   (("/" RelativePathExpr?)
| RelativePathExpr) *| FilterExpr*
drop predicate possibility
 *FilterExpr* *   *::=  * * *PrimaryExpr*
add "." as available forward step (I am ambivalent about this one, but I'll
admit I have written "./foo" before)
 *AbbrevForwardStep*    ::=   NodeTest *| ContextItemExpr*

I also think there is a bug in the grammar. Right now AxisStep requires a
Predicate. The Predicate should be optional. The original XPath grammar
uses this PredicateList thing to deal with zero or more predicates. We want
zero or 1 predicates, Simplest to perhaps do

*Predicate ::= ("[" Expr "]")?*

The ? makes it optional.

There is also a typo in the ReverseAxis production (dangling ") at the end.

Lastly, do we allow () as an expression? Right now the grammar allows this,
because ParenthesizedExpr is "(" Expr? ")" but I'm not sure () is
meaningful in DFDL except as part of a function call with no arguments.
i.e., foo() which is allowed by a separate production for function call
syntax.

On Wed, Feb 6, 2013 at 5:05 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Mike,
>
> More correctly, you mean Step[Index]/Step[Index]/Step[Index], but that's
> fine as that is handled by the definition of AxisStep as it includes
> Predicate.
>
> However removing FilterExpr entirely removes PrimaryExpr and all it brings
> with it, like literals and function calls and the use of "." so your change
> on its own simplifies things too much. What I think you would need is:
>  StepExpr    ::=   FilterExpr | AxisStep
>  PathExpr    ::=   (("/" RelativePathExpr?)
> | RelativePathExpr) | FilterExpr
>
> I can see (at least) one problem with only allowing FilterExpr to appear
> on its own, namely that you lose the ability to use "." in conjunction with
> a path, so even the above is not sufficient.
>
> Looking at what we have done in the original spec, all we did was edit the
> BNF to remove things we didn't support, making what resulted easily
> comparable to standard XPath 2.0. The resultant BNF implies several things
> that we do not support in DFDL, so we qualified the BNF with some notes.
> For example, DFDL only allows the use of Predicates to index arrays, so
> there is a note saying that a Predicate must result in an integer else it's
> an SDE. I think we should do the same for  errata 2.101 - leave the BNF
> alone and add a new note to the list.  And beef up the words at the start
> of section 23.4 to make it clear how the BNF should be read.
>
> Also noticed that the BNF in the spec is not stand-alone as the constructs
> for StringLiteral etc are not reproduced, and rely on the reader reading
> XPath 2.0 spec.
>
> Regards
>
> Steve Hanson
> Architect, Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        dfdl-wg at ogf.org,
> Date:        05/02/2013 23:08
> Subject:        [DFDL-WG] what do we allow in DFDL expressions after "/"
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
>
> In reexamining the grammar for the DFDL expression language, I have the
> following question
>
> In a path Step/Step/Step[Index]
>
> What can Step be? I know it can be ".." or parent::QName or child::QName
> or just an NCName or QName,
>
> Those are all what the XPath grammar calls AxisStep.
>
> anything else?
>
> The grammar can be changed in a very  small way from the original XPath
> grammar if the above are the only possibilities.
>
> the clause
>
> StepExpr  ::= FilterExpr | AxisStep
>
> can just be changed to
>
> StepExpr ::= AxisStep
>
>
>
>
>
>
>
>
> --
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | *
> www.tresys.com* <http://www.tresys.com/>
> --
>  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
>

-- 
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130206/b2896936/attachment.html>