Forms WG FtF Raleigh NC USA, Day 1 -- 04 Feb 2008

<unl> leigh, xmpp not xml

<klotz> Yes, but they bill it in the article as "a generalized XML routing system" so they know it's not just free chat.

<unl> xmpp is even used in some esb implementations as a messaging protocol

<John_Boyer> scribe: CharlieW

Default trigger

John: continuing from Friday's discussion, try to get to high priorities for 1.2

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/Agenda_Feb._4%2C_2008

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

John: added some more explanation to the wiki
... with examples for defaulting behavior
... based on Mark's comments that a group might have several inputs and DOMActivate one the event will bubble to group level
... we might capture that event and reflect it back to the default submission control in that group
... which would then of course cause another round of bubbling
... in an infinite loop
... so we don't have a reasonable way to generalize a UI control as default to be activated from other controls in a group
... rather than dispatch, if you do a send you don't get a loop

Charlie: why is this?

Nick: if you dispatch the event to the action you don't get a problem

John: unless the trigger does a stoppropagage

Nick: you can use your own event

John: not generalizeable
... if you actually press the trigger as a user, you'll get a DOMActivate
... but as the default control, use a *different* event -- this seems wierd to do twice

Nick: you can code the action to fire only on the custom event and it will work in both cases

Mark: we want a convenient authoring notation
... and we haven't been precise about which events are generated from each control...

John: up to now we have no exceptions to events based on target object -- don't modify XML events

Mark: doesn't break XML events to spec out the behavior for stop propagation etc by control
... e.g. for submit behavior

John: but in general for all triggers would be hard to say they stop propagation

Mark: could define new markup for trigger that captures this behavior

John: we still have a problem just to define default behavior for triggering
... in 1.1 now
... you're suggesting that unless we add more markup, we won't have a good solution to default triggers

Mark: yes, but we should do that anyway

John: supposing we do that (tidy up DOMActivate story)...result might be we'd be able to create a default action or UI control in a group using some elaborate pile of markup but it would work
... I'm wondering suppose we do this, could we then see how to encode an ease of authoring shortcut to default triggers

Mark: shorthand would be a new attribute on trigger or submit, i'm the default

John: that's what I was hoping for

Mark: but we should do the tidy-up firsthand

<klotz> s/english/English

john: proposal is to solve the default problem in two phases --
... get markup precision (cleanup)
... phase two is to create the short-hand, along lines of default attribute

<klotz> Is the goal to have a default submission for a form or a default action or control for a group?

Mark: XML Events 2 has an action to stop propagation

Nick: if you have that, does our current markup work?

Mark: yes, but it would be awkward to code

John: that's the XML Events 2 advantage

Nick: but then you could do it with our markup

it would require XML Events 2

Nick: there are use cases where you want to propagate DOMActivate

John: you'd have to put stoppropagate on every trigger in the group

Mark: i don't see use cases with handler both on the trigger and you want to bubble

Nick: default actions for all triggers

Steven: i've needed it once for value-changed, but not DOMActivate

Mark: but trigger is a funny case
... always follows same pattern, trigger ev:event="DOMActivate"...you've said this twice in effect

Nick: but then you'd have trouble controlling whether to stop propagation explicitly

Mark: better inside the trigger to set data up, then do a send
... better to do both in the same block rather than depending on another handler working together
... could have a designated "handler" for when the trigger is actually pressed
... e.g. onActivate as a child of trigger

John: is anybody willing to champion this? carry it forward to authoring shorthand too...
... sign me up for 1.2

<John_Boyer> Solve default trigger problem for 1.2 by coming up with better DOMActivate behavior and then creating the ease of authoring shorthand

<scribe> ACTION: John_Boyer to solve default trigger problem for 1.2 by coming up with better DOMActivate behavior and then creating the ease of authoring shorthand [recorded in http://www.w3.org/2008/02/04-forms-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - John_Boyer

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

Put ref or context on action element

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

John: in order to set context for a repeated set of actions, avoiding need to code it on each action

Mark: is this different from context everywhere?

Nick: i wrote some spec for context on bind

John: but i thought we weren't doing this, rather make child elements out of calculate, readonly, etc and put context there
... i wrote this up in an email
... back to this item, regardless of context everywhere (there was concern in 1.1 about doing this)...
... was concern that a global context would be hard to understand -- too powerful

Mark: in 1.1 i think that was fair
... if some elements support it and some don't that's perhaps more confusing

Steven: and the code says it explicitly

john: i like generally putting context everywhere

Steven: my experience is doing it partly, we miss good usecases
... if it's harmless, we should put it everywhere

John: could be confusing if you expect it to work, and it's missing somewhere
... we've seen this in practice

Uli: what about repeat?

John: repeat is perhaps the most important target

Mark: so there's a good consistency, model attribute, maybe instance attribute, ref, context
... they all work the same way all the way through

John: could be defined once in the spec
... one perhaps confusing thing is we're not saying what happens to the insides of a repeat
... does expressing the context attribute cause a change to the context size and position

Mark: if you say ref is shorthand for context=x, ref=.
... then context means same as ref without binding aspect for events
... ref is shorthand for both

John: so yes it does reset position and size
... which appears to make sense

<markbirbeck> I.e., we should 'read history backwards', so that <group ref="x"> is a shorthand for <group context="x" ref="."> and then write up @context accordingly.

John: within UI binding you lose track of which row you're on if you can't call position and size
... if you have an input inside a repeat then the ref attribute during evaluation you can invoke position and size functions
... to figure out what row you're on and how but the containing repeat is
... whereas with context attribute you lose this by the time you evaluate the ref...still have it for context

Mark: so it's not backwards compatible

John: but it'd be ok if you move the expression to context

Nick: ...

John: not a problem
... anybody interested in championing putting context everywhere and removing it as special attribute?

Leigh: so what does context on instance do?

John: nothing

Leigh: ok

John: so we're being imprecise...put context everywhere where we can currently put nodeset or single node binding
... those sections of chapter 3...where we'd list context attribute
... amend 7.2, insert/delete,

Mark: would be easier to make all of those attribute to apply everywhere
... so why not put them on model, would set context for nested handlers

John: grrrr
... but with nested models might make sense...

Mark: almost like context is implied on the model, on submission context already has implied first instance

John: there are in fact only a few elements that don't have some form of binding
... and allow them to still set a context

Nick: what about host language elements?

John: that seems to be a separate problem, we haven't address well...applying xforms UI bindings on host language elements
... would seem to require global namespace versions of our attributes
... e.g. putting ref on svg elements, rather than xf:ref
... concern about putting context everywhere was more about being toward the end of doing 1.1
... rather than a concern in principle
... it's now in the list of 1.2 possible features
... so we could pick it up and move it forward

Uli: i can do this

<scribe> ACTION: Uli to work on context "pretty much everywhere (see the minutes) [recorded in http://www.w3.org/2008/02/04-forms-minutes.html#action02]

<trackbot-ng> Sorry, couldn't find user - Uli

<Steven> hand

<Steven> shorthand

<Steven> firsthand

<Steven> you've got to hand it to zakim, that that is a really interesting bug

<Steven> hand it to zakim that he says the funniest things

<Steven> hand it to that bot he has interesting bugs

<Steven> you've got to hand it to zakim

<Steven> hand it to zakim

<Steven> hand it to him

<Steven> the bot knows no shorthand

<Steven> to the bot knows no shorthand

<shepazu> handy

<unl> handsome

<unl> handler

<shepazu> unhand me!

<Steven> a glass of shandy

<Steven> secondhand

Proposal to let value override single node binding on output

http://www.w3.org/MarkUp/Forms/wiki/%40value_override_single_node_binding_on_output

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/%40value_override_single_node_binding_on_output

<John_Boyer> http://lists.w3.org/Archives/Public/www-forms/2006Aug/0009.html

John: when you use ref now it ignores the value
... when you want the ref to get the MIPs but override the value from the ref with the value xpath

Leigh: seems like a hack to me, why not use XBL?

John: say more...

Steven: may not have XBL

Mark: when doing RDFa, found it's easier to define how all attributes work together, rather than overrides etc etc
... example seems nice

Leigh: so approaching the same result but from different use case?
... applying behavior generally

Mark: yes, makes rules uniform

John: so add value to input?

Mark: no, don't add value
... take Uli's context example, do something like this for value/ref

Leigh: i could see adding value to this story with context/ref
... just worried about doing this one example as a special case

Mark: agree with that

Leigh: if there's a separate reason for doing this, ok...but this specific example is not compelling on its own

John: but we are still only talking about value on output...not general case
... where else is value used?

Leigh: following this specific use case could get into too many special cases

John: there are other cases, for example value inside item

Leigh: can you put value on label?

John: no, but output inside label with a value

Mark: agree with Leigh...this is looking for a formatting type thing...
... but i'm interested in the consistency of our attribute combinations

Leigh: we should do it if there are reasons beyond this case

John: there are authoring convenience issues...wrapping a group around output is not convenient

Leigh: repeat with group to get relevance loses context

John: lose position and size
... our new context attribute doesn't fix that

Mark: it would if ref were on the same level as context

John: context already means something other than that for insert/delete in 1.1

Mark: this is the result of not doing context everywhere at first
... consistently

John: seemed to be needed to control behavior of attributes on that element, as well as children
... seems consensus is to not accept this as a special case

Mark: i like the general issue it raises, but deal with it consistently
... could do this by putting a label with value under output

John: group trick would be just as good

Mark: but then handlers have to go on group

Leigh: the point of this proposal is that he'd like it to be a single control for styling...doing a group makes this hard

John: i'm still hearing we should not do this now, put in bucket for potential later issues...
... just feel that value attribute is used in too many different ways to easily create the general solution

Mark: but we don't need to go there, just where ref and value are on same element

John: eg. setvalue

RESOLUTION: table putting value and ref together to later issue

John: do we need to respond by mail...

Doug: yes

John: we could put this into the general case of formatting issues...

<John_Boyer> http://www.w3.org/TR/xforms11/#ui-selection-commonelems-value

John: do we want to consider better support in XForms 2.0 for formatting values?

seems like a host language/skinning issue

John: might require knowledge of the application context

Mark: there's no standard way of doing this

Steven: CSS isn't quite strong enough, should we do this or somewhere else?

Leigh: e.g. XBL

Mark: there are lots of platform-specific ways to do this, won't be interoperable

Steven: should be class="currency" then the formatting layer takes over...

Doug: could provide a service to convert to the desired currency...

Steven: would help in adapting to locale and user...e.g. Euros vs Dollars

Mark: could just open an issue in the wiki and work on it there

Keith: doesn't XSL formatting objects help here>?

Mark: all we need is an attribute the formats that output

Steven: it's an issue, even if XForms isn't the right layer to address it...we should ack the issue

Mark: there seems to be a functional issue too...controlling the precision that stuff gets into the data layer

seems like controlling transforms from data layer to UI is separate problem from concrete presentation styling

Steven: seems like it's value-add for user agents to do extra processing for known data types, not all platforms might be able to do this
... nothing prevents you from having an input control that knows it's an integer-only

John: have created an entry in wiki for considering formatting for UI controls, and have added this issue to that page

<wellsk> scribe: wellsk

Starting back

John: other 1.2 possible features

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

John: can't create node out of thin air

Mark: make part of insert element

Create Node capability

<nick> http://www.w3.org/MarkUp/Forms/wiki/Agenda_Feb._4%2C_2008

<nick> http://www.w3.org/MarkUp/Forms/wiki/Create_Node

Mark: recreating xaml here, express attribute or express element
... if generalize would it need value element, origin element, origin element with value, origin element with children
... origin element with ref

Nick: like a nodeset

John: wouldn't use nodeset

Charlie: shallow vs deep in subtree

John: Create Node, here is name, here is node -- only thing missing right now

Leigh: element and attribute from xslt and nest them to make trees

Charlie: not recreate DOM interface

John: not sure we need this

Mark: ability to compartentalize, template, model for templates, reuse them

Nick: from xslt, if know name - make subtree with dynamic and static names
... not just use element

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

John: insertion and setting of value
... if name of element could be dynamically specified?

<John_Boyer> <create ref="parent" nodetype="element" name="child">literal</create>

John: use literal value (string) of create element

Mark: attribute called value or content

John: children or attributes of this element

Mark: if xpath don't need children

<klotz> <xf:create ref="parent"><xf:element name="child"><xf:attribute name="att">123</xf:attribute><my:thing>in my namespace is literal</my:thing></xf:element></xf:create>

Mark: create a dynamic element like xslt
... transform action, previously proposed by David L. on exforms.

John: have to have xslt processor
... not good for phone people

Nick: need to create subtrees, usually a subtree not just one element

John: 1.2 to facilitate authoring, is this much to ask?

Nick: solve it in complete package not simple one

John: action to fix simple cases
... with action to fix in 2.0

Nick: import xforms element, not allow subtrees to be created

Leigh: what's problem with subtrees
... use value element and single node bindings

John: Nick has been saying to drive data for name of the element

Nick: not use element

Mark: why new create when we have insert

Nick: add origin child of insert and add arbitrary elements, to create dynamic attributes

John: Why not add origin child element to insert, come up to actions with well-known patterns

Nick: need general solution with simplier form

John: allow to control names of elements
... question of spelling insert or create

Mark: setvalue instead of just a string, set value of XML
... value is of type XML
... if string value is an element add XML
... instead of string value, <setvalue ref="some/node">John</setvalue>

John: value is synonymous with string value

Mark: value could be xml content

John: interpretation of value has been equal to string, not content

Mark: interpretation doesn't have to be string
... what do you mean by value, doesn't mean a string necessarily

John: can't calculate arbitrary xml

Mark: not disagreing, did not see value is perceived only as a string

John: call it setcontent
... as opposed to setvalue

Mark: processor to figure out rebuild flag if xml content

John: the value attribute converts to string

Nick: value as renedered by form control

John: insert always sets the rebuild flag
... is setcontent reasonable

Mark: i don't mind

<klotz> copy?

Nick: origin child of insert?

John: a new action with added intelligence

Mark: are situations where don't need rebuild

Nick: Are spelling out in spec ?
... if implementation decides not necessary to do rebuilds, inconsistent behavior.
... do something other than canceling

John: insert by nature of adding origin to insert, insert could be intelligent to do rebuild too
... setcontent as a ease of authoring

Nick: to champion this
... will change the 1.2 features list wording of create

Steven: this points into log

Nick: wants to point to minutes

<John_Boyer> time for lunch

Forms-f2f

re from Doug: Zakim, call Forms-f2f

<nick> http://www.w3.org/MarkUp/Forms/wiki/Create_Node

Leigh, are you dialed back yet?

<Steven> klotz

<steeeven> who

eric, we are dialed in to conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), steeeven

<Steven> ebruchez?

Scribe, wellsk

<scribe> Scribe: wellsk

specific actions instead of insert

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

Mark: not certain a priority

<ebruchez> hi I am around, will call in soon

Mark: a last call comment, is insert too complicated, destroy and duplicate issues

<nick> rssagent, make minutes

Mark: at that time, hesitant adding more to insert

John: stabilized secondary behaviors of insert
... create, duplicate, destroy -- all possible but insert/delete handle these general cases

<John_Boyer> We standardized on insert in part to control the eventing

<John_Boyer> it'll always be xforms-insert, even if we use a 'duplicate' or 'setcontent' action now

John: should we break out different behaviors on insert into 1.2

Steve: if it is too hard (insert) we should do it.

<John_Boyer> http://www.w3.org/TR/xforms11/#insert-delete-patterns

Mark: Cherry pick the simple things, should we create a new action

<klotz> thanks

Steven: insert/delete reflect a hole in our constraints processing which may be better described in declarative way

<ebruchez> hi guys, FYI the sound quality is pretty bad

<ebruchez> it doesn't seem like the mike is picking up the speakers well

Mark: different things for simplification, shortcut actions, or think of common things people do in forms
... thinking of more elaborate actions
... repeat of insert/delete -- very common

Steven: work for 1.2, 2.0 has room for big improvement

Mark: making some thing really easy for simplification, or taking mathemitician's viewpoint and doing all things

Charlie: external source attribute reusing generic web service model

John: big ticket items?
... simplified repeat in XForms in 2.0 -- leave there?

Charlie: patterns around repeat -- almost every form application

Mark: when do comples, becomes memory hungry on processor
... if thousands of items, repeat processes thousands, or use 10 items and use code to bring in other pieces of the 1000's of items
... you could show how they should be done
... deal with large lists of data, have given examples
... or say number=x in repeat, then add more in language itself to deal with these cases

Charlie: that is the case from experience
... simplified notation

Mark: Rails has done very well, but do not find suddenly a performance problem, but have run in to performance problem in xforms

John: repeat may be too light weight
... by default get 10 row table
... setting defaults and have markup for the poor performance cases

<markbirbeck> http://www.formsplayer.com/node/346

Mark: can we turn that into a piece of markup

<ebruchez> just FYI it seems that the sound is hopeless :-(

Mark: how you feel you should work it, vs best performance pattern

<ebruchez> will follow the IRC logs though

Mark: key is on bind not repeat
... list of items from page, nodeset = 10 items, 20 items, and then it's manipulating nodeset

<klotz> i put the xforms-scroll-* events on repeat to allow you to retrieve partial data for display, but afaik nobody has made it work yet

Mark: solved problem in action handler
... key thing of this, 4 components: instance data, nodeset on windo of data, action handlers by page size
... my-prev-page, and my-next-page
... gets a nodeset for repeat, triggers dispatch events, next page, previous page - shows view of data

Steven: looking at nodeset and want to show a bunch in a repeat

John: How does delete operate in repeat

Mark: number is only a hint

Steven: not seeing difference in two things

John: can't manipulate attributes for repeat
... write delete for current row, @index-of-repeat

Mark: number is hint and as you move up/down, row index to data is moved into view
... so have to set index on that solution
... have to add index to view index, implementation specific

Nick: we can decide one way, make portable

John: setindex action called for many reasons, an implicit setindex now to get row focused.

Charlie: model on left, events to control refresh on server, build logic around it

Mark: independent of repeat
... just a block of data as you scroll, independent of UI

Charlie: pattern repeat/insert/delete and client/server pattern
... like this because it is consistent with declarative lang.

John: index is between 1-5 only, because that is what is showing. (in a repeat of large numbers)
... memory on server 10,000 nodeset, when you really need a 5 item nodeset to view

Uli: typical problem on Chiba

Mark: on mobile env, could go to server every single request, window size is one page

Nick: parse complete DOM, you can optimize it, when doing large docs...

Mark: can do this now, a new author sees quite a lot going on and writes inefficient forms

Nick: implementors not solving the performance issue
... Dom is in memory to work through it
... not as easy in implementation

Mark: where are you getting information from 20 items or thousand items
... repeat number="20", bind="x", <bind nodeset="x"/>

<ebruchez> I have trouble following the conversation, but when you have large information sets and you want to page through them it seems like a good idea to rely on a backend like a database to get smaller increments of data at a time. Sorry to state the obvious ;-)

Mark: <insert bind="x" at "7000"/>

John: disconnect between the number and bind element refed
... no firm attachment in repeat

<ebruchez> maybe the issue is to have 10000 items in a nodeset in the first place

John: how to optimize from 10,000 items to a few

Charlie: how to provide simplified authoring

John: look at common patterns, and then provide markup for them

Leigh: index change and rebuild get server to provide caching

Mark: window on a window, window on server

Leigh: keeping offset in bind, don't limit to data when 10,000 nodeset is in model
... when knows what offset is
... xforms-scroll-up/xforms-scroll down was added to solve this

John: inside data in model, go get more data to look at

Mark: Ui <-> Server

<ebruchez> I agree with Leigh. I think you will hit more use cases where the large dataset is external and where you don't want to load it entirely in memory. So if improvements are done in this area, it is important to keep these use cases in mind as well, in fact maybe those should be the primary use cases considered.

Mark: window object in middle, receiver with event handlers, firer of events

John: refs and submissions on how to get more stuff on top or on bottom, caching from server

Mark: ADO style

John: original topic, crack insert yo do these common patterns

<unl> lets call it grid

<unl> not grits

John: special case, chuck if on it, add general case for insert to drive behavior looking for. not convinced if a dozen other insert oriented patterns
... is that Xforms 1.2 or 2.0

Charlie: it's xforms 1.2

John: rule of three, 2 is too little, 4 is too much
... this is third big hit, 1) nested modelling, 2)implied modeling, 3) class of these common patterns

Charlie: doable but complex, now to boil them down

John: concept is a value-add

Charlie: wizards pattern

John: higher use pattern
... validation over subtree of data
... to coimmunicate this is a wizard
... end up with arequirements doc
... need document, last call, working draft with 1.2, then people are asking for more ...
... breaking insert into pieces: are we going to defer?

Mark: cherry pick some of them, 2-3 become candidates
... may find we have done most later

John: may not need to list action, cause semantics say certain actions are done

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

John: xforms 1.2 only has two bullet points
... simplification and ease of authoring
... neither may be correct
... sales job for xforms 1.2
... what should it say for these buckets
... Ease of Authoring - making model optional, instance implied
... unified evaluation context - because calculate on UI control, means have control of context of expression
... have <input ref="c" calculate="a+b"/>

John: ease of authoring, <bind nodeset="c" context=".." value="a+b"/>

Steven, Nick: loose context

Nick: which expression, then repeat ref ..

John: Same person is writing markup, making them repeat info is better than alternative

Nick: loose general rule, can't do it on a bind, binds to multiple nodes
... example, calculate c from prev a and b
... abcabcabcabc (that is node elements)
... <bind nodeset='c" calculate="prev.sib@::a[1]+prev_sib@::b[1]"/>

John: <bind nodeset="c" context=".."> <calculate value="prev..."/>
... generate a bind, generate a bind with a calculate

Nick: general case calculate -- loose functionality

John: implicit to control need something other than default

Nick: if need explicit which is not done by implicit binds, then you have to define it -- do it completely
... or remove calculates from others too

John: express data model, binds and calculates
... not .. which would be defaulted

Nick: in UI layer, then calcuclate isn't relevant?

John: having to type ".." all the time is a disaster
... implied structure of Ui is from data, the 99% case is much more valuable to us
... mapping expressed model as generalized

Mark: nick's case would need explicit model/binds
... blue sky designing,

Mark <input name ="b"> <input name="c" relevant=$b" <bind id="b" nodeset="b"/> $b is shorthand for bind

Mark: <output value="$fn +$sn"/>
... <bind id="a" nodeset="a"> <bind id="b" nodeset="b"/></bind> -> a/b[1]

<John_Boyer> http://www.w3.org/TR/2007/REC-xforms-20071029/#idref-resolve

Nick, John: we solved that

John: second para 4.7.2

Charlie: need statement arounnd Xforms is the killer app of web
... related to consuming web services/feeds/social networking
... what is it that needs xforms...

<ebruchez> I do remember we already talked about Mark's proposal for XPath variables defined with <bind>. Some issues with this was that 1) you really want to have variables in the UI and 2) You want variables to be able to hold *any* content, including strings, numbers and booleans (in XPath 1.0), not only nodesets.

<ebruchez> So I was more in favor of a more generic xforms:variable construct.

<ebruchez> (see eXForms for how this can work)

Mark: got to make it easier

Charlie: spreadsheet like mashups -- using constraints

John: what is it we don't have already?

Charlie: advertising
... patterns and constraints with declarative markup

John: simplification/ease of authoring not selling what those ections are describing

Mark: modularize --> many more messages than we have there, what is kller message
... <div> <xf:hint>....</xf:hint></div>
... A good pattern, javascript/ ajax have fns to do this
... have things to sell -- which fit use cases (real use cases) a suite of stuff, give xforms message...
... what AJAX programmers model used all the time
... break things off and bring them into a life of their own.
... javascript/ajax to add xforms into their practices

Charlie: how to change the way we work? Modularization?

Mark: xforms message 1.0, make dtd
... yahoo could add to xf:hint to library
... role has taken on life of its own
... xf:message for xf 1.2, who is to stop xhtml5 to use <message> (no xf:)
... gets more coverage

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features#head-e7a1b9d1817e3a3033d50727e3fb571cfe2d8a2f

Mark: add message module to ajax/dojo

<Steven> Scribe: Steven

Mark: I was thinking that we leave out cross-cutting stuff
... so take help, hint and message

John: Alert?

Mark: Could do
... but HTML inputs can't have children
... They are based on events, the handlers are hidden
... independent of model
... pure text
... Then the cross-cutting stuff joins them all together
... dring...

John: Well, we can have submission with the instances inside submission

Steven: Well, the idea is to factor the stuff out, so that submission just knows that data comes from somewhere
... without saying where exactly
... and then when you use the submission module you say where it coes from, instance in our case

Mark: Take the example of role; there is xh:role, and we say you can use it like that, or import it without namespace (chameleon)

[Mark demonstrates how people do message now with divs, and says that we already package that pattern using the messag element]

Uli: How would you deal with different presentations of message?

Mark: With @appearance

John: Maybe the module approach helps us to move forward with XForms 2

Mark: I think we have to do this as soon as possible

Charlie: We are the X in AJAX
... but I hear John worrying that this may slow us down, but there is no objection in principle

John: Someone has to take submission to decide whether to factor instance out or not
... I'm happy that it is a single chapter at the moment

Mark: Ajax does a lot of packaging of low-level facilities and mapping it to markup, but they are all different
... but we have matched all these things in a standard way
... and then we have the higher-level stuff like dependencies as well
... but the lower level packaging is impoertnant too
... But take DOJO for instance; it has three different approaches to events; there may be something better than DOM3, but at least we focus on just one solution

<markbirbeck> Steven: When you add the module instance you get @ref. (Responding to question about how you get bindings onto xf:message.)

Steven: A module introduces elements that have attribute *sets*
... and importing a new module you can add attributes into the sets

Mark: Note that Yahoo have used XForms, but in their own namespace
... we could supply the module that they use and let them really use XForms
... rather than be just *inspired by* XForms

Nick: Won't modularisation use up all our time for new features?

Mark: I meant that we should produce modules as we go
... like XHTML2 has produced role, access, rdfa
... and will later combine them

John: I got another message from Chris Lilley

Mark: It also facilitates profiles

John: Oh no, I remember, Chris said "No delta specs", I remembered it wrong

Keith: What have we decided as the result of this conversation?

John: Specific actions instead of general insert led to the question what are our three bullet points for 1.2?
... I don't like the term "simplification"
... then there was patterns

Charlie: It's about 'consumability'

John: Which is a very IBM term for making things more approachable for users
... But I need my third bullet point...
... 'abstraction' won't do it

Charlie: Just 'patterns'

Keith: XForms patterns

Steven: Usage patterns, so that there is no ambiguity with regexp aptterns

John: XForms pattern reduction

Steven: Pattern simplification?

Charlie: Declarative rich web application patterns

Mark: It's not about simplification, but about codification

[laughter]

[John edits wiki]

<wellsk> link to change: http://www.w3.org/MarkUp/Forms/wiki/XForms_Future_Features

[live wiki hacking being discussed]

<markbirbeck> Just in passing, here's a post about how 'XForms is an executable pattern language': http://internet-apps.blogspot.com/2005/09/xforms-executable-pattern-language.html

[Discussion of what determines when something is a 'pattern']

Mark: We should definitely retain the simplification for authors
... but modularisation would allow [parts of] XForms to get into more places

<markbirbeck> http://ajaxpatterns.org/Patterns

<markbirbeck> http://ajaxpatterns.org/Popup

<wellsk> http://www.42ndstoysterbar.com/

you finished leigh?

klotz?

<ebruchez> just did

<ebruchez> all right

<nick> Kieth: Call them Modular patterns

<nick> Keith: Construction Patterns

<nick> Ssteven: Composition patterns

<nick> John: What can we Pattern discovery really call?

<nick> John: Grouping control patterns

<nick> Scribe: Nick

John: Where go Same model item property on the same node
... Same model item property goes to composition

Steven: @context everywhere should go to Generalisation

John: Should we change Usability Patterns to Functional and Usability Patterns
... Can we change Usability patterns in Implicit model patterns
... Language Usability patterns

Markb: Authoring patterns

MarB: Ease of Athoring Pattern

John: All of them except @context are model optional ones

<Steven> Lobster time

<Steven> trackbot-ng, end meeting

- DRAFT -

Forms WG FtF Raleigh NC USA, Day 1

04 Feb 2008

Attendees

Contents

Default trigger

Put ref or context on action element

Proposal to let value override single node binding on output

Create Node capability

specific actions instead of insert

Summary of Action Items

Scribe.perl diagnostic output