RE: RIF Working Group needs namespace name for xpath "op"

Since you seem to be generating a complex XML expression tree, why not use the XQueryX subset that covers the operations you need?

I am not sure why you are concerned about the polymorphism. Could you extend on this please?

Best regards
Michael

-----Original Message-----
From: Sandro Hawke [mailto:sandro@w3.org]
Sent: Wednesday, March 05, 2008 6:35 AM
To: Michael Kay
Cc: Michael Rys; public-qt-comments@w3.org
Subject: Re: RIF Working Group needs namespace name for xpath "op"


Thanks for the replies to my comment [1].

Michael Rys writes:
> > Why can't you use the XPath operator instead? Like *?

So, right now in RIF the expression "diffdays > 10" looks something like
this:

   <Xterm>
       <op><Const type="rif:iri">op:numeric-greater-than</Const></op>
       <arg><Var>diffdays</Var></arg>
       <arg><Const type="xsd:long">10</Const></arg>
   </Xterm>

and you're suggesting that instead of having functions be identified by
IRIs we should allow them to be identified by strings out of the fixed
set of strings defined by F&O, like this:

   <Xterm>
       <op><Const type="rif:operator">&gt;</Const></op>
       <arg><Var>diffdays</Var></arg>
       <arg><Const type="xsd:long">10</Const></arg>
   </Xterm>

Aside from the polymorphism issue (below), I don't see a technical
reason why we couldn't do this, but it does seem kind of unnecessarily
complex.  Other functions in RIF (evaluable and logical) are identified
by IRIs, so why should one particular set not be?  In this application,
it seems like a bit of arbitrary complexity.  (I'm glossing over the
qname-to-IRI mapping issues, because I think they're orthogonal.)

> > That would allow you to be interoperable with XPath 2.0
> > implementations, many of which will not use the operator
> > functions as described in the spec for implementation purposes.

Since our expression syntax is different, we'll never be interoperable
without a translation stage.    (Any translation would be complex,
unfortunately, due to the difference in approach to polymorphism.)

Michael Kay writes:
> Like Michael Rys, I'm reluctant to do anything that would encourage the
> belief that the op: functions are intended to be implemented and made
> available in a public interface.

What's wrong with implementing and providing them?  If someone wants to
compare two numbers, why should they not use a function identified as
op:numeric-greater-than ?

> Apart from anything else, this would be
> difficult because they are polymorphic.

Yes, this may be the key motivator.  RIF (at this level) does not want
polymorphism.  We want to say numeric-greater-than and
dateTime-less-than and have them be different.  For one thing, we may
want to require some of them but not others in a given profile/dialect,
and have their presense/absence be obvious from the syntax.

I don't recall all the rational for that decision.  I can try to
reconstruct it (and possibly re-open the issue), if it's important to
you.

> The style of specification that we adopted, that is, defining language
> operators in terms of these notional functions, has unfortunately led to a
> lot of confusion of this kind. We need to bury these functions more deeply
> rather than raising them to the surface.
>
> Perhaps it would be useful if the RIF Working Group could explain the actual
> requirement rather than the perceived solution.

Have my above comments helped clarify?

    -- Sandro

[1] http://lists.w3.org/Archives/Public/public-qt-comments/2008Mar/0021

Received on Wednesday, 5 March 2008 21:28:43 UTC