Forms WG FtF Raleigh, NC, USA, Day 2 -- 05 Feb 2008

<klotz> ok, will dial in now.

<klotz> trying again

<CharlieW> Scribe: CharlieW

<Steven> On the record: http://www.snee.com/bobdc.blog/2008/02/the_future_of_rdfa.html

John: should we continue to XForms 2.0 features or deep-dive into an example module?

Steven: i know how modules work, so i'd prefer 2.0 discussion
... but it's important to see how to make progress on that

Uli: 2.0

John: could do an hour

Charlie: would like to have a template

Mark: we should start with a modularization template, but i haven't gotten in touch with shane yet

John: do we need an overview

Mark: could do that but i also have an example -- using a message on a div

John: let's start with that, then switch over to 2.0 later on

upcoming meetings

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

June 9th-12 in Amsterdam, no virtual days

Tech plenary will be in Cannes, not Paris, two virtual days aforewords

Action element content model

John: currently has "+" requiring at least one element
... we agreed it should be "*"
... should we change this for 1.1?

yes, we should do it

John: it's an easy spec change

Leigh: it's really editorial

Uli: does it make sense?

Leigh: could argue it's not editorial, since we're adding a test case
... but the test is against XML Events, not our spec so it's editorial

John: right, this change would add to the test suite, require support in the implementation reports

Leigh: nice test case for XML Events

John: have we publicized the test suite?

Keith: making changes to chapter 1 to emphasize new features...need to get people looking at it for accuracy

John: time frame?

Keith: about a week

John: do we need a formal issue process for the CR phase?

Steven: don't anticipate many issues

<markbirbeck> ttp://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916

<markbirbeck> http://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916 t

<markbirbeck> ttp://www.yugma.com/app/loading.php?user=&role=0&collsession=203673916

John: I have the action item to change the action element content model

XForms Modularization

<klotz> i can't hear Mark

Mark: does example of modularization in web conf
... most ajax libs have functions to display, e.g. modal dialog boxes -- as encoded in div's or span's as templates
... instead of having multiple ways of doing this, why not use xf:message, xf:hint etc etc
... the example in the demo uses a message, registered on a div rather than an xforms element
... in what we're proposing for the hint module, you wouldn't even see the mouseover event registration

John: how would you do a help?

Mark: still to F1, or to platform-specific help feature

John: but our module would not say that

Mark: right

John: so label could be a module...

Mark: yes, it's handy to have in lots of places
... focus is on the markup, underneath the script can be platform-specific
... to enable the wiring, do show/hide etc
... e.g. for styling, we can just inline some css, whereas in the script world you have to go find the message template and set various attributes procedurally
... as well as control visibility explicitly

John: does this content cause problems for the XHTML schema?

Uli/Steven: yes, that's what modularization is about

Mark: we already have dtd's for xhtml+rdfa
... already on the w3c server

<klotz> +1

Steven: didn't require a new req track activity, just a combination of existing stuff -- power of modularization

John: when people say they need "valid" html what do they mean?

Mark: they need valid against *some* given schema

Leigh: i like the idea of making these modules (help, hint, label) available
... but we need to figure out how to make them available inside message to make them usable
... event model is not worked out

Mark: not sure we need that from day 1 though, we can allow anything inside those elements, no other forms controls

John: as soon as someone does a message+input

Leigh: i'm more worried that we'll decide to change message, for example, and we'll have modularized the old one...

John: certainly one of the problems for message if that you put lots of controls in there, e.g. trigger, ui events will bubble up and cause the message to reappear

Mark: right, but the context is focused enough here that we could get those details right...i.e. no trigger in the initial modules
... then we need to clearly define how these controls behave to avoid these problems
... for example, by narrowly restricting the events you subscribe for (as target not bubble, for example)
... need both target and bubble for different scenarios, but we haven't spec'ed which we need and when

John: we might need to say something doesn't bubble outside of message, needs more xml events machinery

Mark: we would need to be clear in our module, not just attach for a mouseover but only on the element that applies etc
... easier to define since it's a small space

John: when we provide not just message but hint and help too, how would we tell people to make those work if they have controls in them

Mark: in the way i just said, they only fire when element they're attached to is targeted -- this is for implementors not authors
... markup is normal xforms markup
... given we wouldn't have xml events in this first module, we probably couldn't have an explicit event binding for message
... or put onclick="DOMActivate"

c/DOMActivate/message.activate()

Mark: candidate for module #2 might be xml events

Steven: but it's already modularized

Mark: so we could pull this together if we needed to

John: how do i filter on events targeted to my parent, just in xml events?
... could we have a new event like ev:sourcetarget that would allow for this filtering?
... to avoid the bubbling out of our children problem -- retriggering ourselves

<nick> http://www.w3.org/MarkUp/DTD/xml-events-qname-2.mod

John: almost like we want to say "message means stop propagation for all children"...

Leigh: then we won't get submit propagated outside of the dialog

John: but the default processing still happens

<nick> http://www.w3.org/MarkUp/DTD/xml-events-2.mod

John: we really need phase="target" in xml events

Mark: but we could do this in prose, telling implementors what the behavior should be -- offer the semantics not implementation
... we could add xml events from day 1 but that might be too much...need more incremental approach

John: don't we need to specify the joint behavior of these specs?

Mark: these issues arise already today

Uli: is this endless loop really a problem?

Mark: in my example, the message element is a template, moved elsewhere in the tree, so any bubbling of events is not a problem in terms of triggering the message
... we could define the behavior of the module to require this "disconnected" behavior -- in its own display space

John: yes, this would solve a lot of problems
... vs. for repeat where we defined the variable elements to be part of the original tree

Mark: there are lots of details in terms of how the template (and styling) are used to create the instance to be displayed
... so again we just need to specify in prose what we want the bubble/triggering behavior to be

John: problem is we said there's already an xml events profile around, so there's another way to activate the message and one which could well cause the bubble problem
... I want that to mean ev:phase="target"
... so don't we need the document that says how to combine these...
... so it has to go into the message module, which doesn't depend on xml events

Mark: we can talk about dom events in the message module, not xml events
... so we should define the xforms-hint event in this module, but not say how it's fired

<John_Boyer> break

Mark: our module documents might be more informal than a traditional spec
... more like the pattern discussion yesterday
... list elements, examples, give events that are part of the package and their behavior
... effectively have defined the interface
... but elements and event names are still independent of implementation, which i think is preferable

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

John: under our "modularization of existing patterns" category

Message, Event, Hint, Alert modules

Mark: we could just call this the "XForms Message Module"

Steven: yup

John: want to avoid misunderstanding that it can only be used in xforms

Mark: want to use this as on-ramp for xforms

John: so once you have it you might want more xforms

Leigh: must have a download so they can run with it

Mark: right, needs script impl, screen shots, etc etc
... we're part of the ajax world but it's a different approach

Leigh: we're going at this backwards...
... they're not going to be interested in the spec, just the impl
... the spec is the "Cambridge" approach
... we just need working code

Mark: i agree, when it gets to ajaxian the headline is ... "new library available..." i.e. it's about the code
... but the missing bit is the movement toward having standards in the ajax world...we have more than a library, confirms to a w3c standard
... we need to close the loop

Leigh: yes, but it can be done incrementally

Mark: i can do that, but i think it needs the module

Leigh: but your readers don't
... by the time they want it it'll be ready...3 months from now

Mark: if i were to set up a separate site, define the behavior, it wouldn't have the status of xforms

Leigh: yes, it would as a partial implementation

Mark: so i'm hearing that maybe that work should be part of the group

Leigh: this will push it along faster
... you're not inventing new markup, it's refactoring and getting xforms out there

John: i'm willing to participate on the spec side -- it's like a mini-version of submission
... there is spec work to do, it's not just pulling things out, but there are important details

Leigh: or Mark does his code first, says it's part of the xforms wg, we do a draft, etc iterating code first

John: what are next steps>?

Uli: I'd like to have/see Mark's code

John: what are the next steps on code?

Mark: need to combine some attributes into the hint element
... would be great to use in Chiba

John: so will you add phase=target to xml events?

<unl> Charlie, I would love to *help* Mark with the coding

even better

<John_Boyer> http://www.w3.org/TR/xforms11/#ui-repeat-processing

<markbirbeck> Uli...thanks, by the way. :) The plan would be to open source this too, so there will be lots of opportunities to work on this.

The repeat item generation and repeat index update on insertion must behave as if it occurs in response to the xforms-insert event dispatched by the insert action. The index update must behave as if it occurs when the xforms-insert event reaches the target instance element in the capture phase.

John: does this make sense? is there a notion of an event reaching the target element *in the capture phase* ???
... i.e. before any other handlers that might be defined for that event in the bubble phase

<Steven> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture

Mark: i believe there are implementations in html events that put default processing at this point -- before bubbling

John: trying to read xml event spec but getting "abuse of IP address" blocking

<John_Boyer> lunch time

<klotz> http://xformstest.org/klotz/shibumiscript/

<nick> Scribe: Nick

John: Explains the XML eventing model

<klotz> you aren't dialed in..erik andi are here

<Steven> sorry

<Steven> our mistake

Steven: ev:phase:="capture" and ev:target="target' isn't allowed

John: Points out that http://www.w3.org/TR/xml-events/images/event-flow.png is confusing

<ebruchez> zakimthans

<ebruchez> thanks

John: The diagram suggests that there is a capture phase at target

MarkB: It is specified in DOM2 events that there is no capture phase in the target

John: The diagram suggests otherwise

Charlie: The paragraph under the diagram also hints that there is both a capture and bubble phase on target

John: So we need a spec change
... Can we have an XForms implementation that does not have DOM 2 events?

MarkB: Don't think so

John: If you have an event that doesn't bubble, and it reaches target what is the phase then?

<markbirbeck> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow

MarkB: It is bubble

<markbirbeck> Key phrases in DOM 2 Events:

<markbirbeck> First, in 1.2.2:

<markbirbeck> "A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered."

<markbirbeck> Second, in 1.2.3:

<markbirbeck> "Events which are designated as bubbling will initially proceed with the same event flow as non-bubbling events. The event is dispatched to its target EventTarget and any event listeners found there are triggered."

<John_Boyer> ACTION: John to fix XForms 1.1 wording for repeat processing to associate repeat index updating with capture phase on containing model, not target instance [recorded in http://www.w3.org/2008/02/05-forms-minutes.html#action01]

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

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

http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

<klotz> i have been on mute a while

<ebruchez> I am muted

<klotz> is it a scratchy noise?

<Steven> buzzing

<ebruchez> at least my Skype is supposed to mute me

<klotz> ok

<ebruchez> k

<klotz> mm mm mmmm mmm

XForms 2.0

Steven: More stuff working automatic

<klotz> no audio from you now

Steven: A lot of our problems with insert and delete are because we can't define constraints on structure (calculations)

John: We have a bullet 'Better authoring of repeating constructs'

Steven: You are asking for a synchronization, is it really a calculate
... Typically it is not the structure that you are putting in that is the structure that you want to send back

s/is not the structure that you want to send back/that is the structure that you want to send back/g

John: What sis the bullet point?

Steven: Structural constraints.

John: What does it fix?

Steven: I have to reconstruct the use cases I hit in the past

John: Web services is a good example

Steven: This is just a function

<Steven> but I believe we want constraints as well

<John_Boyer> ACTION: Steven to write up use cases and basic design for Structural Constraints [recorded in http://www.w3.org/2008/02/05-forms-minutes.html#action02]

<trackbot-ng> Created ACTION-450 - Write up use cases and basic design for Structural Constraints [on Steven Pemberton - due 2008-02-12].

John: Going back to the list (enumerates XForms 2.0 (high priority))

Steven: Packaging could be one of the new features

John: Don't we have that partially in XForms 1.2 with 'Custom XPath functions'
... What is extra in XForms 2.0?

<ebruchez> ouch, gotta work on those XPath functions

<markbirbeck> I.e., http://internet-apps.blogspot.com/2005/04/css-xforms-dependency-engine-and.html

<markbirbeck> :)

Charlie: Unifying our UI based events and model based events

<ebruchez> can't hear Charlie well, but I don't see improved UI events in the list of 1.2/2.0 features

<ebruchez> i.e. replacing the IMO broken current UI events

John: That is Drive UI (presentation) properties from data and calculates

Charlie: But also constraints on UI properties, e.g.: If the size of an image is dependant on a slider, when the size passes a threshold a red border is shown

MarkB: Whole the document is the instance

John: If we have structural constraints and the whole document we don't need repeat

Steven: Steven explains that repeat is constructional constraints plus ....

<Steven> Repeat is structural constraints from the instance to the UI

<Steven> We also need such constraints between instances

<Steven> and Charlie says between UIs

John: It is hard for digital signatures if the whole document is data, then you no longer have the markup as a separate thing to sign

<html>

<xf:model>

<xf:instance>

__delta__

</xf:instance>

</xf:model>

<body>

__presentation__

<body>

<ebruchez> I assume ;-)

<dsig:signature url-to-doc>

subtract delta

</desig:signature>

<ebruchez> oops, wrong correction then

<ebruchez> sorry about that

John: Explains why if the whole document is the instance, breaks a signature of an application (document without instance data)
... My reference system can refer to attributes in the whole document, but if you keep following the attributes expressions you get to the data

MarkB: Instsance is then meaningless

John: Instance has a meaning, it is the only thing that can change

<ebruchez> I understand how this helps XML signatures, but it also sounds restrictive

MarkB: That is leap for XForms, but it isn't a leap compared what they are doing in AJAX

<ebruchez> i.e. "all state information must lead to XML data"

MarkB: Example before we had output mediatype="image/*" we had the value of the output to create the image element. But now you can't nor more dynamically change the size of the image

John: I like driving UI properties from data, but I want to identify the 'data'
... Now we say that the referencing engine is limited to the instance

MarkB: <xf:output ref="..." style="with: { @width}" />

MarkB: In current browsers it is easy to handle 'unknown' elements, but not for values of attruributes

<xf:superbind nodeset="xf:output/@style"/> will enable our calculates on the style attribute on xf:output elements (style="with: { @width}" )

<xf:output ...>

<xf:???? ref="@width" class="..."/>

</xf:outpu>

<xf:output ...>

<xf:constraint origin="@width" newvalue="here()/css:style/@width"/>

</xf:output>

<ebruchez> that's what you should be able to write

klotz: This can solve styling rows with alternating color

<xf:output ...>

<xf:constraint nodeset="@width" target="here()/css:style/@width" calculate="."/>

John: One of the things that jumps out is integration and generalisation

<ebruchez> (gotta go for ~1 h)

<klotz> http://xformstest.org/klotz/shibumiscript/

mute, klotz

<markbirbeck> http://www.svgopen.org/2004/papers/ConstraintSVG/

<markbirbeck> e.g.: c:constraint attributeName="x" value="id('c')/@cx"/>

<klotz> sorry dunno what the noise was.

<John_Boyer> ACTION: Steven to write strawman proposal for Repeat Pattern [recorded in http://www.w3.org/2008/02/05-forms-minutes.html#action03]

<trackbot-ng> Created ACTION-451 - Write strawman proposal for Repeat Pattern [on Steven Pemberton - due 2008-02-12].

<Steven> I hate to say this (sort of) but we were doing presentation constraints in the late 80's. Here is a paper by a student of mine from 1992: http://www.cwi.nl/ftp/CWIreports/AA/CS-R9262.pdf

<Steven> "Maintaining presentation invariants in the Views system"

<img....>

<xf:output ref="x">

<xf:setvalue ev:event="xvc" ref="document()//img[@id='blurp']/@y" value="a+b"/>

</xf:output>

</img>

Steven: Explains two way constraints

Charlie: Components and constraints then?

John: Some don't fall in any of those two
... Some are maybe just usability patterns

MarkB: Explains how 'XBL' can be added to XHTML as a module
... Submission should be a Module, that isn't 'constrained' to XML

JohnB: In my view that is the instance module, that is causing the support of for example JSON
... Should 'Need event for submission result received' be part of XForms 1.2?

Charlie: Where are the models listed?

JohnB: There is no clear line between XForms 1.2 and 2.0 with modularization

<klotz> yes, i am still muted for my sins

<ebruchez> ok

<klotz> i am muted

<klotz> break?

JohnB: Is it ok that 'Integrated Validation and Recalculation' is under constraint

Uli: What does it mean? Make it one step?

JohnB: Correct

Nick: Isn't Integrated Validation and Recalculation a sub bullet from MIP functions (when using validity in a calculate/constraint)

Uli: What would be the name the now we have recalculate and revalidate

John: Just recalculate -> validity should be checked automaticly

JohnB: a favorite of mine is User-defined model item properties
... Better expression of default values maybe is XForms 1.2
... Do we need to do work for SCXML integration

<ebruchez> I don't think so

Charlie: Not for us I think, they need to consume our model
... When we modularize everything

JohnB: I think we should create a bullet Modularization not in XForms 1.2 nor in 2.0, it is separate of the version

MarkB: Explains XBL and XBL 2.0

Leigh, Charlie and MarkB: Have a discussion about advantages and disadvantages of XBL

in relation with using it in XForms

JohnB: I updated http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features
... Goes over the XForms Modularization bullets
... Adds modules Action binding module, Repeat module,Switch module, Group module, Selection controls module, Simple controls module

Charlie: Why is Selection controls module a separate module?

JohnB: Not sure, we can have Core UI module and Container module
... What is a good name for non-container form controls

<ebruchez> "leaf" form controls?

<klotz> core or basic would imply you plan to expand around them; leaf or single-node would imply you plan to expand to ones that dont' bind to a single node

<unl> Atomic would be fine, since it indicates that these do not contain other controls

<ebruchez> Well, in a tree of controls, they are actually leaves. Extension occurs by adding controls to container controls.

JohnB: We will add a xf:model model

discussion about the names of the modules

should we call it XForms model module or Model model used in XForms

MarkB: Maybe not all modules should be XForms modules (e.g: label)

JohnB: If label becomes a module should we reconsider the binding mechanism, not only containment, and for example reintroduce the 'for' attribute

<Steeeven> trackbot-ng, end meeting

- DRAFT -

Forms WG FtF Raleigh, NC, USA, Day 2

05 Feb 2008

Attendees

Contents

upcoming meetings

Action element content model

XForms Modularization

Message, Event, Hint, Alert modules

XForms 2.0

Summary of Action Items

Scribe.perl diagnostic output