[Versa] Issue 100A proposal, extension functions

[Michael Olson]

On Sep 3, 2005, at 1:48 PM, Chimezie Ogbuji wrote:

> On 8/29/05, Michael Olson <Mike.Olson at fourthought.com> wrote:
>>
>>
>> I would like to propose adding a section 7.7 to the specification.
>> This section would discuss function names.  We would also change the
>> "identifier" production in the EBNF for a function-call to match a xml
>> qname production.  function names without a prefix would be assumed to
>> be in the "versa core function" namespace.  All other namespace must
>> have been registered with the implementation yada yada yada.
>
> I plan on finishing up this section with the following requirements
> for resolving function references:
>
> The default namespace for function name resolution is:
> http://rdfinference.org/versa/0/2/
>
> (should this change since we no longer own that domain?)

Yes.  put it in as this for now, I have a todo item to fix all name  
space references when we do  have a home for the spec.

>
> It is automatically bound to the 'versa' prefix.  The core functions
> are defined in this namespace.  If a function is referenced with a
> namespace outside of the query processor is required to do the
> following:
>

Sounds good so far.  I would say that an implementation is also  
required to add a few other name spaces (on a different topic).

rdf
rdfs
dc?


> First check if the namespace is bound in the current context (defined
> in a prefix declaration).  If it isn't, raise an error complaining
> about the unbound namespace prefix reference.  If it is, check if any
> function with the matching namespace and name are registered with the
> query processor.  If so, invoke the function with the appropriate
> arguments.  If there is no matching function, convert each argument to
> a resource (following the conversion rules - a little trickier if the
> argument is a literal) and return the objects of all statements where
> the subject is any of the arguments (converted to resources) and the
> predicate is identified by the URI of the function name.  I.e.,:
>
>
> ns:functionName(res)  :=   resource - ns:functionName -> *
>
> (where ns:functionName is not registered with the implementation)
>

I like this, plus it solves the issue of adding all of the functions  
like "rdf:type()" etc.

Should we have processor produce a warning?

In general I have been ignoring error handling and warning requirements  
but it is something I would like to cover.

> If there are no arguments, raise an exception stating that the
> referenced function is not registered with the implementation.  I
> think this is more useful than simply complaining if the function
> isn't registered, and allows the use of functions as First Order
> Predicate mappings.  These can be overridden by registered extension
> functions.  In this way, you can allow certain  'high-level' semantics
> to be provided by extension functions that override certain predicates
> (in the same way that CWM uses predicates in the log namespace --
> http://www.w3.org/2000/10/swap/log.n3 -- to perform high level RDF
> management).
>
> Beyond this, it is completely up to the implementation to determine
> how extension functions are registered.
>

Agreed.

Mike

> Chimezie
> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management