Re: Discussion points for <control/>

I have updated the requirements according to the discussion at the last 
call, as a basis for further discussion today.

Steven

REQUIREMENTS FOR <control/>
 Behaves like an inbuilt command
 Uses recognizable interfaces (eg @ref @resource etc)

      <control resource="mycontrol.xhtml" ref="instance('data')" 
label="..."/>

PRIVACY
 An XForm that can be embedded contains an element in the model (called 
<interface/> for now) that:
 1) identifies which (sub-)instance receives the data,
 2) receives events arriving from outside,
 3) is the target for events to be sent to the outside.

        <interface ref="instance('values')"/>

 Each form (embedder/embeddee) only has access to data granted by the 
other.

DATA
 Data can be passed in; data can be passed out.

 Interface is bi-directional mirroring between a (sub)-instance in the 
embedding form, 
 and a (sub-)instance in the embedded form.
 To the embedded form it looks like it is referencing one of its own 
instances.
 The embedding form sees the changes (more or less) simultaneously as they 
are made.
 There are clearly requirements to the two instances matching in shape in 
some way.

 Either side can bind to an attribute 
(https://www.w3.org/2022/11/11-forms-minutes#t01),
 but in that case both have to bind to a text node,
 and the the embedded form's referenced item must not have children. 

 QUESTION
 What happens if the shape of the data on either side is different? 
 Eg an attribute or simpleContent on one side, and an element with children 
on the other?
 Is an event fired? Is the embedded form inactivated?

INITIALISATION
 How do we determine if the embedded form gets initialised from the 
referenced data
 or from its own data?

EVENTS
 Events can be passed in (by targetting the <control/> elements)
 Events can be passed out (by targetting the <interface/> elements)
 Both forms are insulated from events from the other except 
 for events specifically targetted at communication between the two.

 Events should perform the same as normal.

 QUESTIONS
 Options: 
 1. Events targetted to <control/> and <interface/> perform the same,
    and so bubble up from the <control/> or <interface/> in the dispatching 
form,
    therefore appearing in both forms.
 2. We introduce a new action, say <signal/> with the same/similar 
attributes to <dispatch/>
    which causes a <dispatch/> to happen on the other side of the 
interface,
    so that the event only appears in the form being signalled to.
 3. Something else?

 What are the ramifications for xforms-ready if any?
 Should it only be fired when all embedded forms are also ready?

INDEPENDENCE
 A form should be able to be used both embedded and free-standing.


EXAMPLE

 <control id="process" resource="process.xhtml" ref="data" label="Before">
     <action ev:event="FINISHED">
         <setvalue ref="done">1</setvalue>
     </action>
 </control>
 ...
 <dispatch name="STOP" targetid="process"/>

 ------------ process.xhtml
 <model>
    <interface ref="instance('values')" id="external">
        <action ev:event="STOP">
            ...whatever...
     <dispatch name="FINISHED" targetid="external"/>
        </action>
    </interface>
    ...
 </model>

Received on Friday, 25 November 2022 12:57:57 UTC