Weekly Forms WG Teleconference

25 Jun 2008


See also: IRC log


Nick_van_den_Bleeken, Charlie, +1.919.254.aaaa, +03491211aabb, wellsk, ebruchez, John_Boyer, prb, Roger, Steven
Uli, Leigh




<scribe> Scribe: Charlie

<Roger> I think Rafael is not coming, but anyway Thanks Charlie...


John's dog

he has allergies

runs into things, poor devil

but is cute

moving along...

upcoming telecons

please fill out summer questionnaire

link is in the agenda


<nick> I'm going to be off for one week first or second week of august but not sure yet which week

July 16 most number away

should we cancel?

would need another chair since John is away too

poll: call on 16th?


nick could chair july 16 if there's a call

could be enough people to have a useful discussion of modules

need work products to have useful conversation

conclusion: proceed with nick as chair for july 16

for july 23rd, need chair too

nick can do this one too

<Steven> only 6 have replied

John: Thanks!

good demo at the backplane call on ubiquity integration in dojo...do we want a repeat demo on july 2?

thomas or i can do this if there's interest

perhaps yugma would work on opera since webdialogs seems not to support it

firefox on mac or windows is ok

conclusion is to use webdialogs

XForms event


Steven: enthusiastic response, content taking shape, nothing formal yet

W3C has expressed interest in some form of sponsorship

John: what's the anticipated size?

Steven: 250 "ish"
... last time XForms event in London, oversold 100 slots within 2 days, anticipate response will be good

John: similar experience at NY emerging technologies group
... normally draw 50-75, we got 300 or so for XForms
... Just in NY State area
... who are likely attendees?

Steven: insurance and finance industry last time had large turnouts, also local govts
... have contacted folks doing impls for govt, they would like to demo
... seeing lots of XML takeup in govt sites in the UK, e.g. RDFa
... also, French implementation of XForms in progress, also expressed interest in coming. have asked for test suite for 1.1
... Concentre is the name of the impl

John: should connect with Keith...

Input Mode Appx E


Steven: working on it...in progress

John: most other 1.1 issues have been worked on
... Nick...could you regen the action item list?

Nick: yup...had some work impacts

XHTML2 access module



John: steven requested review from our group

Steven: we didn't get any LC comments
... would like to at least point out folks have read it and are ok

John: NIck posted a response, thumbs up

Nick: yes, a quick read...didn't find any issues

John: Steven, could you give us the overview pls?

<John_Boyer> http://www.w3.org/TR/2008/WD-xhtml-access-20080526/

Steven: currently access key is mixed with the markup itself
... Access creates an element for accessibility (or other purposes, e.g. phone) separately in the document
... in principle could have different access methods for different devices
... binds keys to roles as well as ids
... also for other event types as well, not just keys

John: first question, is I notice key="s" if user hits s this takes to that element?

Steven: might be alt-s or some other escape key, depending on user agent
... can't override std bindings for user agent, and all access points must be available even if there aren't key bindings (e.g. menus)

Nick: can be overridden in user agent?

Steven: these are hints, user agent has last word
... in the sense of user preferences

John: user-specified settings override user agent defaults
... or author-specified settings
... what happens with conflicts?
... does the user get notification?

Steven: no notification, but all access points must be available in some way or another...

John: no advice on how to achieve that?

Steven: no normative requirement on that, no

John: any known practices?

Steven: yes, one is accessibility binding is different from the chrome binding to avoid clashes

John: another question, in addition to role, can target id

Steven: role is for group of elements marked with role, id is for one particular element

John: how should target id behave in xforms repeat?

Steven: good question
... for example, what about URLs ending with # and ID?

(how does this relate?)

John: coming from outside document in, we'd use current index of each nested repeat
... i.e. we'd apply indices implicitly

Steven: so this is an xforms semantics not access
... up to markup languages also where they put this element, imagine it goes in head but not required

John: for xforms it matters where the ID reference is coming from.
... does the actual keystroke behave as event dispatched to access element?
... if you have access in repeat, which access would the event go to?
... might be something we have to say in xforms, to pin down these issues for us
... would this be worthwhile as LC feedback?

Steven: yes, but it's very xforms specific
... same/similar problem in CSS

<nick> I always thought that the css selector matches all the repeated elements

John: if access inside repeat, are there other impacts?

Steven: pls send in this comment to let WG think about this

John: ok

<scribe> ACTION: John_Boyer to submit LC comments about access relating to behavior in XForms [recorded in http://www.w3.org/2008/06/25-forms-minutes.html#action01]

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

<Steven> tracker, status?

<Steven> trackbut, status?

<Steven> trackbot, status?

request for comments on XML Events 2

John: Charlie already posted, is this satisfactory

Steven: yes, except that today as a result of our call sent request for extra advice
... given forms has lots of implementors
... at what point should listeners be registered? what should we say?

John: seems like early registration for declared handlers is appropriate
... then as processor is starting, new repeats are created which would then trigger their handlers

Steven: second part of the question is should XML events markup be live?
... i.e. if the markup is changed somehow, should the registration follow those changes?
... I could imagine this would cause problems...

John: it's not something we support now, no
... we need action item for some of the implementors to comment on this...

<nick> we neither, but it could be an interested features ;)

John: any vounteers?

Paul: this would be quite difficult for us as we're not in control of the DOM

Nick: chiba doesn't do this either

Steven: I'd be happy with a clear "no"...
... if you're scripting the DOM then you can just set up the listeners you want directly

Nick: there's a remove event listener in XML Events 2, right?

Steven: yes

Nick: but you can add it declaratively and then add by script

John: could it be re-added later on? if removed by script?

Steven: yes
... XML Events markup is for registering handlers at some point early in document creation, then we're done

hmmm...it seemed to me that there was an interesting step toward more dynamic function in XML Events 2

John: if you add then remove a handler then persist, doesn't seem to be any record in the document?

Steven: right, this but is ok

John: can you declare a listener that is "off", i.e. declared but not connected?

Steven: no
... but you can create a handler and then at some future time attach a listener

John: having a way to persist the current state of handlers and registrations is important

Nick: no worse than doing this in script

John: same problem i have with switch states...
... current selected case of switch needs to hold across serialization

NIck: always registered, just uses "if" to decide if it's active so it will also be serialized

John: profiles of XML Events 2 applied to archival document formats...might want to give this guidance
... action item to roll this up?

Nick: i can do it

<scribe> ACTION: nick to respond to additional questions on XML Events 2 to XHMTL2 WG [recorded in http://www.w3.org/2008/06/25-forms-minutes.html#action02]

<trackbot> Created ACTION-474 - Respond to additional questions on XML Events 2 to XHMTL2 WG [on Nick Van Den Bleeken - due 2008-07-02].

Specifying initial value




Nick: gives overview...

John: i had assumed we'd use something like "default" attribute

Nick: we had also discussed "initialvalue" don't recall where we came out

John: aside from naming, other issue (see 0097.html) in streamlined syntax but the way it affects the canonical xform is to populate generated instance data
... there's no MIP called default
... doesn't translate well to canonical xforms

Paul: do you mean in existing xforms?

John: yes, we're looking at 1.2 as both streamlined and also extensions to regular xforms
... those mods which are needed to support the streamlined syntax
... e.g. the context attribute to get around ../ notation in calculates

Nick: when new item is inserted, does it get a default value too?

John: yes
... also has implications on "row template"...see example in 0097.html
... prototype row is easy place to put defaults for repeats

Nick: what about when node bindings change?
... can bind to empty nodes, should defaults be applied then or stay empty?

John: my opinion is that default was imposed at creation time rather than rewiring
... is default or initial value a feature of streamlined syntax only, at doc init, or a feature in core xforms as part of live running document?

seems like a big change for core xforms

<nick> rssagent, pointer?

<nick> rssagent, make pointer

John: question to the group is: anybody uncomfortable with initial value for 1.2? importing it from streamlined syntax. those in core xforms would have instances with pre-seeded values

Paul: do you mean in core xforms the default attribute would do nothing? or insert these values if empty?

John: the former, default would not do anything
... helps in the interpretation of name attribute
... helps to generate the implied instance
... if you want defaults in core xforms then you'd do this by writing out the starting instance explicitly


Paul: i can see how it could be used in core xforms in lazy author mode
... but i agree

John: we can revisit when we have spec-ready text, but it seems like we should write this up for now...need to decide on the attribute naming
... did we decide on "initial-value"?
... or "default"?

Paul: one issue with default, is if you delete data from this node and then submit it, would get reinitted before submission...

<nick> I updated http://www.w3.org/MarkUp/Forms/wiki/Add_support_for_default_values_without_the_need_of_an_instance_element to refelct what we've said until now

Paul: just "initial"?

<nick> I have nothing against initial-value ...

John: or maybe "initialize" but do we not like att names that are verbs, steven?
... as opposed to dashed values
... we do have "calculate"
... any objections to "initialize"?
... ok, let's use that
... does seem better than initial-value

automate boolean-from-string() on the boolean MIPs (relevant, readonly, constraint)

readonly, constraint)


John: xpath has rule that string converts to boolean based on empty or not
... not the common sense expectation
... of the contents
... leads to lots of frustration

Nick: i see this is hard to understand but see two problems in doing this automatically
... first is if you're using an expression inside another one, need to do this explicitly since we can only impact the outermost expression
... so we're also no longer backwards compatible with 1.1, also with other langs like xquery, xslt
... for nodeset to boolean

Paul: although i agree, not sure if the standard meaning in xpath is what's expected
... expert authors will still have workarounds

Erik: in the 0077.html email i wonder what is the idea of the implicit conversion, when does this happen?
... in xslt 2.0, when adding attributes on variables, the value is guaranteed to be of that type
... in xforms we don't assign with the type property an xpath type...
... if we had the ability to assign the type to a value (not only for boolean) then we could do automatic conversions when using them

Nick: there is a conversion from nodeset to boolean by using boolean function
... some authors make assumption that string with "false" as values, this converts to false, not true

<nick> http://www.w3.org/TR/2001/WD-xquery-operators-20011220/#casting-boolean

<nick> switching to XPath 2.0 will fix our problem

Erik: should follow pattern from underlying w3c recommendations

John: problem is actually not false, but boolean when converting nodeset with children
... how should we convert the nodeset for xforms?

Erik: not right that it doesn't make sense (current semantics)
... clearly there are use cases for existence test
... rather than value test

John: seems like that's the edge case

Charlie: worries about baking too much "policy" into xforms -- maybe put this in streamlined syntax?

Paul: also not backwards compat.

John: possibly attack with streamlined syntax
... add the appropriate conversion function in accessing the implied instance
... seems similar to ../ problem

Erik: funny construct, lots of magic
... hard to specify clearly

John: can say it always applies boolean-to-string but again maybe we do this in streamlined syntax

<John_Boyer> <input name="x" relevant="y"/>

<John_Boyer> convert to core XForms

<John_Boyer> relevant="boolean-from-string(y)"

<John_Boyer> boolean-from-string(true())

<John_Boyer> returns true

Erik: when would a user write relevant in streamlined?

John: that's what they're usually writing

<John_Boyer> <output name="LineTotal" calculate="Price * Quantity"/>

<John_Boyer> or

<John_Boyer> relevant="$isChild"

<John_Boyer> relevant="isChild"

Erik: in this case, perhaps the typing of the node goes further
... we don't use the type in xpath expressions
... we could do the right conversions given this type knowledge in either streamlined or core xforms syntax

Paul: that doesn't sound very streamlined, form author has to know about types

Nick: but it's automatic

Summary of Action Items

[NEW] ACTION: John_Boyer to submit LC comments about access relating to behavior in XForms [recorded in http://www.w3.org/2008/06/25-forms-minutes.html#action01]
[NEW] ACTION: nick to respond to additional questions on XML Events 2 to XHMTL2 WG [recorded in http://www.w3.org/2008/06/25-forms-minutes.html#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/06/25 16:19:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/inick/nick/
Succeeded: s/out/our/
Succeeded: s/diffferent/different/
Succeeded: s/remove/add/
Succeeded: s/move/more/
Succeeded: s/this/but/
Succeeded: s/and then delete/and then submit/
Succeeded: s/(relevant,/(relevant, readonly, constraint)/
Succeeded: s/had/hard/
Found Scribe: Charlie
Inferring ScribeNick: Charlie
Default Present: Nick_van_den_Bleeken, Charlie, +1.919.254.aaaa, +03491211aabb, wellsk, ebruchez, John_Boyer, prb, Roger, Steven
Present: Nick_van_den_Bleeken Charlie +1.919.254.aaaa +03491211aabb wellsk ebruchez John_Boyer prb Roger Steven
Regrets: Uli Leigh
Agenda: http://lists.w3.org/Archives/Public/public-forms/2008Jun/0063.html
Got date from IRC log name: 25 Jun 2008
Guessing minutes URL: http://www.w3.org/2008/06/25-forms-minutes.html
People with action items: john_boyer nick

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]