- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Mon, 03 Dec 2007 13:19:08 -0500
- To: Christian de Sainte Marie <csma@ilog.fr>
- Cc: Dave Reynolds <der@hplb.hpl.hp.com>, public-rif-wg@w3.org
> Michael Kifer wrote: > >>>> > >>>>>I made a proposal that we should treat builtins using the same mechanism as > >>>>>modules. [...] > >> > >>>Dave Raynolds wrote: > >>> > >>>>Isn't the URI enough to avoid clashes? > >> > >>Why do you need more than that to identify built-ins? > > > > I do not. (see the quoted text below) > > So, does somebody object to external functions being identified by their > type (rif:iri) and IRI? I recall Sandro said that it is undesirable from the point of view of forward/backward compatibility, but I forgot why. > E.g. the Uniterm used to represent a call to the XPath fn:dateTime > function would have as its "op" the following "Const" (if I got it right): > > http://www.w3.org/2005/xpath-functions/#dateTime^^rif:iri > > (or, in XML: > <op> > <Const type="rif:iri"> > http://www.w3.org/2005/xpath-functions/#dateTime > </Const> > </op> > <arg>...</arg>) > > Btw, does it follows that, if a function name's type if rif:local, the > function is a logical function? What is "logical function"? Something that is defined by the ruleset itself as opposed to a builtin? Then, I think, it does follow. > And can a function whose name's type is rif:iri be a logical function? > Why would one want to use an IRI instead of a local name? One might be referring to a function defined by an external ruleset. (If I understand correctly what you mean by a logical function.) > >>>But, on the other hand, the same builtin may be defined by different > >>>libraries, and the module system may open a way to use different libraries. > >> > >>Are you talking about different implementations of the same built-in? > >>Here again, if we are talking about RIF-BLD built-ins, isn't that out of > >>scope? > > > > Why is it out of scope? This kind of considerations are a fair game. > > I am not saying that this is what I would push, but this kind of > > extensibility is not a bad idea. > > Well, whether and how to point to an implementation of an external > function is metadata, so, it is at least out of the scope of a > resolution fo issue 40... I am not sure whether I understand what you said, but here it is just part of a general scoping mechanism, which is in scope (mentioned in the charter, albeit in the narrow sense of negation.) --michael > > Christian > >
Received on Monday, 3 December 2007 18:19:56 UTC