Forms WG Virtual FtF, Day One -- 15 Oct 2008

<Charlie> hi all!

<Steven> already done John

<John_Boyer> thx!

<Steven> Scribe: Steven

<wellsk> espound wisely

John: Now I have to say something smart
... Thanks for minuting that

(For John it is 6am)

Modularization Architecture

John: If we go to the wiki
... we can use that to drive discussion

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

<Charlie> so one thing i wanted to get from this is a review of how many and what relationships we want between modules

John: So, what does the model module look like?
... The bullet points give a sketch of the structure
... and suggests what gets injected into the other modules
... the model assumes the existence of an instance

<Charlie> how can the bind module insert itself into model?

Steven: So do we want the minimal model, or the maximal?

<Charlie> that seems to violate encapsulation

Steven: I would have thought we need to have the minimum you need in a document (instance+submission?)

<Charlie> more reasonable perhaps to have model import bind

Steven: and then other modules insert themselves into the model as needed

John: I agree
... there is a struggle here on how to divide it up into schemes

Charlie: It is hard to understand how bind inserts itself into model if we want it to be standalone

<klotz> bind and mips are different;

<klotz> bind is like xml events

Steven: It depends on the aim of the wiki page: does it list the construction of our final model
... or the structures of the models as they will be published?

John: Then there is the question of the division between behavioural and syntactical issues of modules

Charlie: It makes sense to talk abotu the model requiring instance as a module, even though syntactically there may be zero instance elements in the model

John: Is there any sense for any other module to be required my the model module

Steven: Submission?

Charlie: What would be the value of requiring it?

Leigh: Documents that need to read information but doesn't nee dto return data don't need submit

Steven: Just because you don't need to use it, doesn't mean to say it shouldn't be there

Leigh: How do we combine modules that don't know about each other?
... If someone wants to do submission in a different way, we can supply the hooks, but if we don't supply the hooks they can't

John: Events may be the only mechanism we have

Leigh: I think we should be more flexible

<klotz> two separate issues:1

John: Can you describe what the issues are?

<klotz> 1. How do we write our modules such that they can be combined with some subset of each other, and with future modules, without specifically referring to each other with "may/must" clauses that effectively turn the existing set of modules into a monolithic system?

<klotz> Issue 1 is concerning the schema for the markup.

<klotz> 2. How do we do #1 for processing model (i.e., instead of "here is where to validate if you're using the validation module"). Instead, perhaps use XML Events or IDL to define external interfaces for modules, or injection points.

John: Take submission. Do we look at it from the viewpoint of the submission module, or from the model module?

Leigh: Events are not really the right currency for describing these things
... submission doesn't require a instance, just a source and sink of data
... We have to find the right cut points so that people can mash up our functionalities
... otherwise we will have nothing more than what we already have

<nick> yes

<nick> yes that is correct Leigh

Steven: There are several ways of doing this: a module that contains things that are optional; the paretn includes another module; a module inserts itself into its parent, or a driver combines two modules
... depends on what we want from the standalone modules

John: We realise that there could be bind/submission etc in model, but it isn't the model module that mentions that

Steven: I agree

John: Well, how about the bind module

Steven: Do we want bind to always exist in a model? I can imagine a doctype that allows binds, but with an implied model

John: so is the model there, and invisible?
... I think there is always a model

Leigh: This doesn't help the Javascript user
... to say that there is an implied instance
... better to say that the instance module is one way to provide those things
... but I don't want to rule out the other approach

John: So are we any further on the model module?
... it has an element called model
... an abstraction of its content that other modules can contribute to

Leigh: Submission, action, instance, bind

John: Schema
... Take 5

<nick> I can do it

<nick> Scribe: Nick

Leigh: I believe model only exist to hold other modules
... model is almost a container language
... model can import the instance module, but it should not import the submission module, the driver module should do this
... We don't know how to generalize the instance module for now, this can happen in the future

<Charlie> back

Leigh: Model can specify the extension point where actions can be plugged in
... There is going to be more then one module that define actions
... It also defines a scope

John: Why would they use a model that only contains instance

Leigh: Model should be as small as possible

John: Does it needs the actions?

Leigh: For the scoping

John: The binding attributes do the scoping

Leigh: The model shouldn't include the actions module, but should define a group where other modules can add actions to
... The model can include actions, data and the logic
... The modules should add them-self to those extension points

John: What are the layers

Leigh: presentation, data, data types and logic (bind and actions)

Charlie: SHould I take the actions out of the instance module?

John: The actions module is disappearing due to XML events 2
... Top level bullet should be data layer
... second is Scoping and containment specs build on top of that to build the logic layer

Leigh: Model does the scoping for xpath, and data types

John: It seems to a that we have a second set of things, a model module, a declarative way for logic behaviour
... Bind, xml schema, MIPs seem to go together
... The first bullet is the data model layer
... The second was was called model module, it could be called declarative logic layer

Leigh: The child specs should be consumable on their own

Charlie: Can we recap?
... now we have the data island (no actions) the second is the xforms instance which injects actions, is this still in sync with what we said today?

or should we create a third module wit the actions

John: It makes sense
... We should first figure out what the first buller point is, its child bullets and how they relate

Charlie: (Explains what the data island now contains)

John: What does the second module add

Charlie: The three actions

Leigh: Explains that we need to try that insert and delete can target the events to the correct elements without importing the instance module
... Tries to solve the problem of decoupling with an instance attribute

John: I updated the wiki page

Leigh: XForms 1.2 will use the data manipulation module which imports the data island module, so the XForms 1.2 module doesn't import the data island module
... Solving the problem seems to be a lot of work, so I will rest my case, I'm out of ideas

John: src and resource should be added by the submission module

Charlie: What is the data island module doing then?

Leigh: Does it do inline data

Charlie: Yes
... It does the magic for creating the shadow DOM
... I don't see how we can do data manipulation without the data island

Leigh: instance has an id and defines the instance attribute to override the evaluation context

John: the data island already add instance function, but it could also introduce the attribute

Leigh: I say we should add the instance attribute to the SNB
... The data island introduces the instance element, the instance function and the instance attribute in the SNB
... We remove rsc and resource attribute
... loadDocument will go away, instance IDL will stay
... The instance() should go to model because it is a scoping thing

John: It should stay because if you don't have the model you still need to instance function
... Maybe the binding attributes module can add the instance() function, or maybe lower because you can do XPath without the binding attributes
... Maybe we are doing to much modularization

Leigh: Maybe you need to be able to go from element in the shadow dom to the id of the instance

John: Updated wiki

The data island module

* instance element with possible single child element

* IDL functions for getInstanceDocument() and replaceInstanceDocument()

* The src and resource attributes are either added here or by submission

* Adds instance() to one of the XPath functions module

* Adds our two parameter id() function to some XPath functions module

* Add instance attribute with IDREF content that other modules can use to refer to identified instance elements

Leigh: I wouldn't call it DOM
... Maybe it could return the element not the document, and replace will replace the root element not the document

nick: don't we support comments as siblings of the root element

John: yes we do

Leigh: OK, I'm convinced it is a document not an element

John: I updated the bullets again

The data island module

* Create instance element that provides data separately from the document

* instance element may have id attribute and may have child element

* Create instance attribute with IDREF content that other modules can use to refer to identified instance elements

* Function for getInstanceDocument()

* Function for replaceInstanceDocument()

* The src and resource attributes are either added here or by submission

* Adds instance() to one of the XPath functions module

* Adds our two parameter id() function to some XPath functions module

John: Not sure about rsc and resource, they don't exactly do the same thing as submission

Charlie: Being able to get data from a remote location without the submission module would be nice

John: External data module?

<Steven> Thought - are src/resource just syntactic sugar for a [submission replace="instance"]?

Leigh: The manipulation module should add src and resource on the instance module

John: resource on submission behaves different then on the instance element

Leigh: OK
... It sounds optional

John: We say the instance function is optional to implemet

<Roger> * !!amazing, how many things zakim, can do !!!

<Roger> Sorry, but I have to go.

<Roger> bye.

<klotz> http://xformstest.org/2008-10-15.txt

<John_Boyer> scribe: Leigh

<klotz> http://xformstest.org/2008-10-15.txt

<klotz> ACTION: John Boyer to add instance() and two-parameter id() functions to the binding attributes module. [recorded in http://www.w3.org/2008/10/15-forms-minutes.html#action01]

<trackbot> Sorry, amibiguous username (more than one match) - John

<trackbot> Try using a different identifier, such as family name or username (eg. jkugelma, jboyer)

xhtml modularization does that

(multiple modules in one spec)

<klotz> http://xformstest.org/2008-10-15.txt

<Steven> +1

<unl> +1

+1 talk to you all tomorrow

<Steven> "Bye bye"

<unl> great work!

- DRAFT -

Forms WG Virtual FtF, Day One

15 Oct 2008

Attendees

Contents

Modularization Architecture

Summary of Action Items

Scribe.perl diagnostic output