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: Fri, 25 Jul 2008 16:54:09 +0200
Message-ID: <4889E911.4060700@ilog.fr>
To: Christian de Sainte Marie <csma@ilog.fr>
CC: Chris Welty <cawelty@gmail.com>, kifer@cs.sunysb.edu, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>


Maybe we could take the opportunity of a slow summer to progress on the 
issue of externally defined Frames.

As I wrote in [1], I understood, at F2F10, that an external frame was a 
frame in an external data source. I did not like the idea of handling 
the access to external data sources on a construct by construct basis, 
but since you insisted and nobody else objected...

But the explanation in BLD seems to say, either that an externally 
defined frame is a frame where the data model (slots etc) is externally 
defined ("externally defined objects can be accessed using the more 
natural frame-based interface" [2]), or that, when a Frame is external, 
it is really the slot that is an externally defined method ("...could be 
an interface provided to access an externally defined method..." [2]).

Both interpretations might be problematic: the first one would imply 
that we deal with references to externally defined data models on a 
construct by construct basis; as for the latter one, if it is the method 
that is externally specified, then it seems that the slot should be 
External, not the Frame...

Can you clarify, please



[1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0028.html
[2] http://www.w3.org/2005/rules/wg/draft/rif-bld/#Terms

Christian de Sainte Marie wrote:

> 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.
> Cheers,
> Christian
>> 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 Friday, 25 July 2008 16:08:50 UTC

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