[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [s-ramp] Fwd: Explanation of s-ramp query grammar problem
Kurt, Regards, Vince Brunssen Senior Software Engineer Emerging Technologies 512-286-5487 (External) 363-5487 (T/L) Kurt T Stam ---07/18/2012 09:39:34 AM---Hi Guys, Eric works with me on S-RAMP and while implementing the Query API he
Hi Guys, Eric works with me on S-RAMP and while implementing the Query API he noticed that our query grammar does not supports literals to be arguments in function calls. Would it make sense to update the grammer slightly? Thx, --Kurt -------- Original Message --------
Problem: As defined, the S-RAMP query grammar does not allow literals to be arguments to function calls. Relevant Grammar: FunctionCall ::= FunctionName '(' ( Argument ( ',' Argument )* )? ')' Argument ::= Expr Expr ::= EqualityExpr EqualityExpr ::= ForwardPropertyStep '=' PrimaryExpr PrimaryExpr ::= Literal | Number | '$' PropertyQName I condensed the grammar a bit (took out boolean _expression_ definitions and whatnot) to illustrate the point. You can see that the only way to get to a PrimaryExpr is on the right-hand side of an EqualityExpr. Example: /s-ramp/xsd/XsdDocument[classifiedByAnyOf(., 'taste')] The example above breaks down as an artifact set with a predicate where the predicate is a function call with two arguments. The second argument is expected to be PrimaryExpr: ArtifactSet [ FunctionCall ( RelationshipPath, PrimaryExpr ) ] But the grammar states that an Argument must be an Expr, which does *not* allow it to be a simple PrimaryExpr. Proposal: Update the grammar, changing Argument to be defined as: Argument ::= PrimaryExpr | Expr This is the simplest grammar change that will support the example, but it is not the only one. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]