W3C Forms Working Group Virtual Face-to-Face Day 2 -- 16 Oct 2008

<Charlie> Scribe: Charlie

Data accessors module

aka data manipulation module

John: is this the right place for serialization as currently stated in the wiki?

e.g. for some subtree, do the serialization

is this submission or a property/service of an instance itself?

things other than submission might want to use this

this will interact with the model when MIPs are involved and validation

from an impl point of view we can see how model serialization can overload the default...

what do you all think?

Steven: hmmmm

initial feeling it's not the place

seems more to do with submission than access

Uli: me too

should also consider other data types than XML

doesn't look like it belongs to instance

Charlie: -1

John: how do I comment things out in the wiki?

Model module

is there a top level name other than model that includes all these related functions?

grouping these under the Model Layer set of specs

flattening a bit the space of specs

looking at model element as container, but not necessarily requiring all of the following components

we'll have a schema to show the required/optional content of model

any suggestions for what goes in model?

Leigh: recall it had optional instance

then some empty content groups

for other modules to insert into

<nick> should the instance module not just say 0 or more

<nick> because an implicit instance is also controled by the instance module

Nick: does model module need to say 0 or more, or just ref the instance module?
... lazy authoring can imply an instance even if it doesn't occur syntactically

Leigh: can imagine some languages might want to say exactly one instance (perhaps SMIL state?)

Nick: would have thought model provides insertion point, and instance controls how

Leigh: this seems to be a case where the model needs to know about the instance spec
... vs. a separate driver module

Charlie: seems like model gets to decide on the policy for how many instances to include

Model defines a functions attribute, declaring extension functions being used

as in current practice

sort of a "must-understand" attribute

<nick> doesn't the driver module needs to that

Charlie: should this actually go on model?

<nick> because I could see another language having other functions by default

have to worry about the case where people avoid using this attribute by stipulating their function is in the namespace URI defined for extension functions

is this attribute really useful?

Leigh: doesn't really address whether the form is coherent and will work
... dog analogy

<nick> I we allow modules to add functions, then each module can add its functions, and maybe model can add an XPath function that you can use to check if a function is available one that allows you to check if a module is available

Leigh: we have a larger problem around module coherence

Property function

supports version, conformance level

could be the function Nick was describing

<nick> I think it should go there

model historically has been the focus of this type of descriptor

<nick> which modules are available

space separated list beginning with "full" or "basic" to allow for extension descriptions

not well defined yet what this string includes

impls can use own qualified names but not unqualified ones

e.g. locale or user agent

could be extended to allow listing of available modules

leave here?

Model attribute added to SNB NSB groups

injects attribute and amends calculation behavior for evaluation context, pre-processing step to consider model

RRRR actions as well as events?

maybe rebuild and recalculate should be added by calculate module

only need dependency graph when you're calculating

relevant/readonly MIPs are atomic

is this true?

they could have calculates

<nick> Shouldn't: revalidate be added by the validation Module

<nick> refresh should go to the UI

Leigh: model is a mini-container spec sets context for evaluation and for insertion of other modules

<nick> and reset can go to the data accessors module

Nick: can reset be used on model to define the scope over which instances should be reset?

Leigh: instances might also maintain their own shadow data

Charlie: yes, that's how it's currently described in the data island module

John: yes, reset knows the instances in a given scope

could also be done with instance function

Nick: then reset wouldn't be needed

John: right, maybe instance function is in the wrong place

if you only have a data layer, then reset on data island / accessor ...

Leigh: if you only have an instance, does this require you to maintain the original/old data to do reset?

might be easier not to require them to do so

inline is easy, but loaded by submission is expensive

(various debates about "expensive")

Leigh: may be too much function for simple users of data island
... raises question of whether we want resettable data islands

John: even original HTML forms can do this

Leigh: that's why we put this in

(physics analogy)

Leigh analogy_count++

Leigh: could get out of control...where do we draw the line?
... why not intermediate checkpoints, rollback, undo?

John: leaving both reset action and saved state on the model seems to make sense

Leigh: can see multiple options

John: i'm seeing that reset is too much for instance layer

Leigh: how will model get the data ?

John: will have to ask the instance

Leigh: this seems consistent

John: let's rephrase the logic around data-instance-load to clarify that users can dispatch this event to trigger the loading behavior

not just a cancelable notification event

consensus is to have model support the reset behavior by interlock with the load/getinstancedocument behavior in instance

John: lets consider refresh action and event

are those defined by model module or by UI module?

seems like the UI module

until you have binding attributes as UI binding you don't have targets for value-changed etc

john_analogy_count++

going up a hill to the UI module at the top

John: who defines the model events? construct-done, etc etc

Leigh: the model

John: yup
... what about xforms-ready?

Leigh: driver module, xforms driver

happens after UI is initialized

John: if you have a UI module

default behavior model-construct-done then ready with nothing in between if you have no UI

Leigh: the top level spec, driver module, seems to have to control this

John: introduces xforms driver module in the wiki
... behavior can only be added via prose in the spec
... nothing in the processing model is visible in the surface syntax

Leigh: so there may need to be more IDL on the model to support the driver

John: model's participation in refresh might be to provide a change list

Leigh: seems like we need to add this capability to the model
... responsibility for doing the refreshing of controls is in the UI module

John: so model module needs to provide change list but it's up to actions and modules like calculate to contribute to that change list

Leigh: who runs the RRRR sequence?

John: model adds the notion of deferred update to action processing
... more likely deferred update concept added by driver not model

<Steven> +1

<Steven> here

<unl> here

<wellsk> Scribe: wellsk

TPAC: XML security Group: 11-12:30

Meet with Roland perhaps after lunch on Monday 2:00

Monday morning: continue Module construction

Submission or UI

Change list in model module

changes: 1) calculate 2) set value 3) external DOM access

in past DOM Access that impl can provide copy and manipulate it

then manipulations go into real DOM

impls listen to DOM mutations

which contribute to change list

perhaps setvalue changes can do this

Charlie: low level use of IDL for modifications
... giving means to do this

John: modules listen for DOM mutations

to reflect DOM changes

into data layer

Charlie: may not be 1-1 correspondance with chnage list and DOM mutations

John: UI binding expressions concerned with low level changes

added: "by listening for data mutations, which may come from setvalue, calculate, or external DOM access)"

Doesn't matter which module, it's a service of the model

other consumer is calculate module

takes change list for starting point to evaluate dependency processing

UI and calculate are consumers of the change list

drives changes to UI

Charlie: this is not the dependency list, this is the change list

<Steven> s/nhot/not/

dependency graphs doesn't get into endless changes

do we want to move to bind module?

Bind module

<nick> the bullet points are ok

Defining bind element

<nick> rebuild isn't in there now

has nodest attribute

<nick> and I have two exception events extra

Change from nodeset attr to Node Set Binding attributes

and Add @bind to SNB and NSB bindings

<nick> Model Item Properties Attribute Collection

adding model attribute to bind element

adding context attr to bind element

<nick> right

<John_Boyer> <bind nodeset="c">

Note that this adds model attr to bind ? and Note that this adds bind attr to bind ?

<John_Boyer> <bind context=".." calculate="power(a*a + b*b, 0.5)" />

<John_Boyer> <data> <a/> <c/> </data>

don't need extra ".." for the calculate attr

also doesn't change node to shich MIP applies

otherwise would make context useless on a bind

<John_Boyer> <bind context="xyz" nodeset="c" calculate="abc"/>

nodeset="c" resets nodes for which the MIPS apply

context isn't applied first -- the model attr is

<John_Boyer> The expression of the nodeset in the bind is what changes the node(s) to which the MIP applies

initial in-scope evaluation context

evaluate context attr in first place

then model attr is processed

then instance attr processed

then context attr processed

each making modification to inscope evaluation

context may not mean much with nodeset bindings

creating dependencies within binds

those binds with nodeset are evaluated before those that don't

Nick: downside not all nodeset evaluations are the same

creates cross-model binds

bind operates only within its model, or discontinue the bind

if bind elements is model A and can contribute to model B -- perhaps it doesn't make sense for model attrs?

Can bind determine if nodes belong to a model?

if bind has model attr and nodes with a model other than my owner -- then ignore the bind

Does bind module live inside the model module

Can use bind element with out expressed model?

if so, need an implied model

because binds scoped to a particular model

Is it a dependency we don't want?

Leigh: scoping to host document, model is a mini-host

John: needed to talk bind module and then model module with contributions to bind module.

Leigh: model provides the scope
... container for binds
... if no model, then implied model global to document
... scoped to containing thing

John: Form tag

Leigh: Form is a diff container other than model
... WebForms A uses Form module, not model module
... lower level specs using virtual versions of higher level specs like Model

<nick> The id resolution of the binds

Leigh: doesn't want this...

<nick> and the nodeset bindings

John: instance data with nodes associated with binds
... binding attributes group contain a model attribute

Nick: bind with id attr scoped to model

issues of bind attr can be taken separately

Bind attr is treated separately from model attr

topological sort problem on bind element -- not supported right now

Leigh: what the scope was...
... model attr, inst attr

can't use data from a different model from data nodes...

bind element should make a determination of model scope

binding attr module evaluates in scope, model module adds to binding module to add scoping resolution

Leigh: if outside model, implied model -- scope would be document?
... same problem scoping with model attr

John: bind module has to know model module to know model attr was added to make the change
... Model module provides scoping to bind module, but model can't do that.

until model attr is resolved..

Model module scope restrictions on bind module and instance module, bind element not select model other than what contains it.

Leigh: do we want bind outside a model?

John: on bind element need nodeset attr, some use of context attr,

clear use for instance attr

headaches with model attr and binding attrs added to bind group

Nick: model module to define model attrs
... if same model, you're done

John: if message action, contains UI binding, would resolve only within model
... Model level, model specific binding attrs?

Leigh: @model and @bind not good on Bind element

John: model module needs to do scoping
... on binding attrs on descendant elements.
... Model module provides scope limiting behavior to binding attributes and instance functions invocations

The context attribute changes context for other attributes but does not, in and of itself, change the node to which MIPS are applied (e.g. if no nodeset is expressed)

Bind module provides a bind element with associated set of nodes to apply MIPs

determined by nodeset itself or in-scope evaluation otherwise

binding attributes module, give me results of binding attributes

scribe: No new results because ref or nodeset not expressed

This module needs to be able to answer the following questions:

* What is the initial inscope eval context of this element?

* What is the amended inscope eval context of this element?

* What is the result of the SNB or NSB?

* Was there an expresssed SNB or NSB (as opposed to the result being equal to the amended context)?

Break for hour

<John_Boyer> zakim is not answering...

<Charlie> -1

<John_Boyer> well, context conferencing system guy is answering, but he keeps hanging up before asking for the code.

<Charlie> he won't stop talking for me

<klotz> Keith and I are on.

<John_Boyer> I'm trying a third time, will be another couple of seconds

<zakim> prob doesn't like you nw John -- after teasing him

<unl> john, zakim is mad at you

<John_Boyer> I thought that might be the problem

<nick> zakim won't accept the passcode

<Zakirn> Hi John

<John_Boyer> Hi Zakim, it seems you do understand "you substitution"

<Steven> I am

<nick> I'm also going

<Steven> Mark said he was planning to come Tuesday

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

<klotz> scribenick: klotz

<Steven> RDFa already has @datatype

Mark said that was OK.

<nick> but what if they are conflicting

<nick> 2009-02-03

<span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"

datatype="xsd:dateTime">

September 16th at 4pm

.

<Steven> like this: 2008-10-16

<Steven> today

http://www.w3.org/TR/rdfa-syntax/

http://xformstest.org/2008-10-16.txt

http://www.thaiopensource.com/relaxng/nrl.html

http://xformstest.org/2008-10-16.txt

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

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff.html#evt-revalidate

<Steven> ok

<Charlie> Scribe: Charlie

<Steven> charlie++

relevant module

Nick: question on who will trigger the execution of this module?

for readonly as well

John: seem to have moved these decisions up to the driver level

a model doesn't know when to RRRR

and model module itself doesn't understand those concepts

since they've been injected from other modules

hence need for driver

that owns the "lifecycle" overall

Nick: MIP related events are targeted at UI controls...this module doesn't know about them

John: UI binding module seems to manage refresh so should do this too

Nick: how can that module know when MIPs change?

Leigh: Erik has mentioned that value-change should happen in the control

John: yes, we're moving in that direction

but for now we have the change list mechanism

each MIP module has to produce this info to be passed into the UI module for refresh and event dispatch

e.g. need operation to get list of changes, and also to clear list

on each MIP module

Leigh: probably not good to get too bogged down in details right now...e.g. potential synchronization problems between get and clear list
... doing a separate spec on metadata attached to the DOM would be a useful outcome here

John: yes, to support custom MIPs

need more extensive mechanism to handle types on custom MIPs -- beyond booleans which we currently have

Leigh: there's nobody who has packaged their DOM extensions for metadata into a standard spec

John: maybe for WebApps WG

Leigh: this would be our MIPs spec

John: i see...we should write the MIP module and then use it for our current ones

Leigh: yes

John: do we have to write that now?

Leigh: it will fall out of the ones we have to do anyway

Uli: we already have use case for custom MIP

filename and mediatype for uploaded data

needed during serialization

no easy way to look back at the instance data from upload control

so we put this in a form of custom MIPs

Leigh: Chiba uses same DOM node factory to store internal info

leigh_analogy_count++

cooking frogs

John: is that the bind module?

itself?

do we need a separate spec?

Leigh: +1

Charlie: +1

<nick> "Model item properties are infoset contributions made to instance data nodes can be distinguished along various axes."

Uli: what about the "user data" spec for dom?

in DOM level 3

<nick> from the spec, that is in the current bind spec

John: that could be an impl technique for our declarative level spec
... adding an item to the bind module bullet list for element version as alternative syntax

Leigh: or <mip name="x" value="x"/>
... what should it be called?

property, name, value

value could be calculated

or with element content if constant

John: setvalue, inset, delete, instance replacement all have to respect readonly MIP

not just consumed by UI layer

Leigh: we have xforms data model plus decorations

John: we have readonly decoration, but setvalue has to respect that MIP

readonly module (etc) has to specify restrictions on MIP processing

Leigh: what happens if you try?

John: just doesn't happen
... also involves submission

partial instance replacement needs to be enforced/checked

parent/ancestor checked for readonly

readonly is only MIP handled this way

on earlier topic of custom MIPs, see DOM Level 3 UserData: http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-setUserData and http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-getUserData

Leigh: DOM impl has metadata properties and when implementing readonly use those properties

so our DOM impl will be extended to respect readonly and access methods would be extended to enforce this

the readonly module says when you give out a DOM reference it comes with these extended APIs

John: wording about readonly could be inserted in the data island spec and then inherited around to consumers of that spec

let's pick up with submission and UI on monday

- DRAFT -

W3C Forms Working Group Virtual Face-to-Face Day 2

16 Oct 2008

Attendees

Contents

Data accessors module

Model module

Change list in model module

Bind module

relevant module

Summary of Action Items

Scribe.perl diagnostic output