[Bug 23643] [UPD 3.0] Convenient operator for transform expressions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23643

Christian Gruen <christian.gruen@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #22 from Christian Gruen <christian.gruen@gmail.com> ---
I have reopened this bug (sorry for my perseverance):

1. First, I would like to quote John Snelson's concerns, which I share:

> [...] I think the precedence for the transform with expression is wrong.
> I propose we move it to between CastExpr and UnaryExpr, so that it is
> situated along with the other textual operators, and so that a simple map
> expression can occur on it's left hand side without parentheses.

2. I'm still wondering if one or two tokens, such as "transform" "{" (as John
proposed in Comment 13), or even simply "transform", would not be sufficient. I
had to think of my initial feature request, in which I suggested to move the
new expression between AndExpr and ComparisonExpr:

  AndExpr        ::= TransformExpr ( "and" TransformExpr )*
  TransformExpr  ::= TransformExpr ( "transform" ComparisonExpr )?
  ComparisonExpr ::= ...

I am pretty sure I have overseen something, but from the answers given so far I
could not explain to myself why...

 a)  X and Y

...is a valid expression whereas it seems that...

 b)  X transform Y

would not be valid. Could someone possibly give me an example that demonstrates
the problem? Or does the problem only occur if the TransformExpr is moved
further down in the grammar?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 15 December 2014 19:50:15 UTC