W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: BLD: externally defined frames

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Tue, 01 Jul 2008 16:43:40 +0200
Message-ID: <486A429C.5020909@ilog.fr>
To: Chris Welty <cawelty@gmail.com>
CC: kifer@cs.sunysb.edu, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Chris Welty wrote:

> Michael Kifer wrote:
>> The purpose of using external frames is exactly the same as that of using
>> external predicates. It is just a different interface. It can be 
>> provided for
>> external objects, while external predicates is an interface for the 
>> regular
>> (non-object-oriented) builtin calls.
>> I would like to better understand what you and Christian had in mind. 
>> From the
>> F2F I understood that csma had right understanding of the purpose of that
>> feature. If the added wording is not what he expected then maybe it 
>> can be
>> improved (once I understand what is confusing there).
> I didn't quite get what Christian thought it meant, I hadn't thought 
> about it deeply but I guess I was expecting (based on your description 
> at the F2F which more or less sounded like your 1st para above) that 
> extern(s[p->o]) was syntactic sugar for extern(p(s,o)).

At the F2F, I had understood that an external frame was a frame from an 
external data source (something like a module). I did not like handling 
the access to external data source on a construct by construct basis, 
but since you were insisting...

But you explanation in BLD makes it sound like it is really a frame 
where the slots etc are externally specified (that is, refering to an 
externally dpecified data model). I do not like the idea of dealing with 
external (and user-defined) data model on a construct by construct basis 
either, and that interpretation is different from the previous one, 
which is disturbing.

Then, when we discussed that with Chris, I understood that he was 
thinking of external frames as externally specified methods: that is, 
frames where the slot key is an externally specified method (not just 
the name of an attribute). Which would be nice to have, but that would 
not be the frame that is external; and that understanding is different 
from the previous two, which makes the whole thing very confusing.

So, in the end, I was totally confused about what external frames are, 
and I think, with Chris, that the best option is to mark them AT RISK, 
so that we can discuss them, and change them if necessary, without 
having to come back to before LC.



> I'm not sure what to make of what it actually is, I need time to think 
> about it, and would rather not rush a final decision.  Again, the 
> proposal is to leave it as is in the BLD LC spec but put it at risk, 
> which gives us some flexibility to understand it.
Received on Tuesday, 1 July 2008 14:43:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC