Re: BLD: externally defined frames

Michael,

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

Cheers,

Christian

[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