[Versa] Updated ebnf with no conflicts

[Jeremy Kloth]

On Monday 26 September 2005 10:45 am, Michael Olson wrote:
> Could be, then just leave it up to the implementation to figure out
> what to do with
>
> ext:function(rdf:type)
>
> Which could either mean "call the function ext:function with a
> qname-constant as the first parameter" or "call the function
> ext:function with a function reference as the parameter"

Yes, exactly.

> The biggest problem (and the reason I added the symbol) is that
> rdf:type is both a qname-constant and a function reference and can be
> interpreted as
>
> ext:function( <rdf_namespace/type>)
>
> and
>
> ext:function( all() - rdf:type --> *)

Easy.  It is a matter of bindings.  If a function exists in the function map 
for "rdf_namespace/type" use it, otherwise perform qname expansion.

> So an implementation will even have a problem determining which way to
> evaluate this expression.
>
> Unless we say that "all functions that take a function reference must
> explicitly state in their documentation that they only except a
> function reference at this point in the argument list, or at this key
> word"

I don't see that as a problem as XPath functions do that all the time.

> Even that does not solve our problems, because if functions are truely
> first class data types then the expression
>
> all() - rdf:type -> *
>
> Can interprete the predicate query as either a function reference or a
> qname constant.
>
> In my mind it boils down to we need to differentiate a function
> reference from a qname constant in the grammar.  And "&" felt the most
> natural to me.

I see them being differentiated by bindings alone.  If the qname (in expanded 
form) is bound to a function where a function-reference is allowed, use it.  
There may be other issues I'm missing, but this doesn't seem difficult for an 
implementation to do.

-- 
Jeremy Kloth
Fourthought, Inc.
http://fourthought.com/
http://4suite.org/