Re: RIF+XML data ready for publication

Yes, editors notes will suffice. This is still a WD, after all.

Cheers,
    Gary

-----Original message-----
From: Christian De Sainte Marie <csma@fr.ibm.com>
To: Gary Hallmark <gary.hallmark@oracle.com>
Cc: public-rif-wg@w3.org, sandro@w3.org
Sent: Fri, Oct 22, 2010 15:43:15 GMT+00:00
Subject: Re: RIF+XML data ready for publication

Hi Gary,

Gary Hallmark <gary.hallmark@oracle.com> wrote on 21/10/2010 18:25:36:
> 
> the following suggests that the slot name may only be a literal string:
> 1. For all the [nodes]XDM e ? E, 
Itruth(Iframe(IDM(e))(IC("expr"^^xs:string), 
> RIFValue(e, expr))) = t (true) for any well-formed XPath expression,expr
> , for which RIFValue(e, expr) is defined; 

I see: "Ic" makes the difference, in the clause.

I mean, the clause is about the interpretation of "expr"^^xs:string, 
Ic("expr"^^xs:string), not the (literal) constant itself.

By definition of fn:concat, Ic(fn:concat("ex" "pr")) = Ic("expr") (for 
instance).

> Another problem with using strings for xpaths is that any typo in 
> the xpath is still a string, and is therefore syntactically valid, 
> but will give unexpected results. Therefore I suggest again that we 
> use a new symbol space, e.g. rif:xpath, rather than overloading 
xs:string.

I see your point. 

On the other hand, under the translation paradigm, that may not that much 
a problem: if there is a typo, either your original rule was wrong or your 
translator has a bug; in either case, it is not RIF's problem. I mean: 
garbage in, garbage out!

Do we want RIF to allow this kind of checks? Personally, I do not think 
so. I fear a dangerous slope (remember the discussion about rule language 
VS rule interchange format?): if we want to go in that direction, using 
XPath/XSD-CD expressions as strings is only a little part of