W3C

- DRAFT -

Forms WG FtF, TPAC Lyon, Day 2

02 Nov 2010

See also: IRC log

Attendees

Present
Nick, Raman, Uli, John, Jaehyuk(observer), Leigh, Eric
Regrets
Chair
Steven
Scribe
Steven

Contents


<scribe> Chair: Steven

<scribe> Scribe: Steven

[Morning session, spec hacking and other action items]

<unl> http://www.sklar.com/badgerfish/

JSON

[Uli posts a link to Badgerfish]

<nick> http://www.w3.org/2005/rules/wiki/Round_11

Steven: We don't need badgerfish, because its aim is differnt: to encode general XML as JSON
... we only need to read and round trip existing JSON
... so our requirements are simpler\

:-)

Steven: The correct format for internal links in the wiki is: [[#my-id|text to be shown]]
... and then use <span id="my-id">bla bla bla</span>

I have now corrected the references in the wiki-spec

http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki

Steven: Nick is now doing some edits to test out the XHTML production
... then I shall correct the definition links
... I note that there are two (non-normative) refs that are in the spec that we don't use: ODF 1.1, and XForms Basic

http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki

Transform

John: I wondered if Uli can live with the function version of transform

Uli: Of course
... but I would like to see an action version too

Nick: Why? You can create the action version with the function version

<John_Boyer> action version is "insert blah blah blah origin="transform()" ...

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

Nick: <insert ref="whatever" origin="transform(...)"

<John_Boyer> http://www.w3.org/TR/xforms11/

Steven: In the wiki-spec, you have to write <nowiki>[</nowiki>[[#ref-xforms-1.0|XForms 1.0]]<nowiki>]</nowiki>

Lunch

<klotz> hi uli (unl) i called in but they're not back from lunch yet.

<unl> no, apparently not ;)

<unl> btw: todays conf code is 26632

Anybody awake?

<unl> Steven, Leigh was here about 10 minutes ago

oh good!

<klotz> hi

<klotz> apparently the conference ended.

for lunch

<klotz> i called it but it closed at :18 when I disconnected and now it's not started again yet.

01<nowiki>[</nowiki>[[#ref-xforms-1.0|XForms 1.0]]<nowiki>]</nowiki>

<cite id="ref-xforms-1.0">

http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#References

http://www.w3.org/MarkUp/Forms/wiki/Category:XForms12

Transform (more)

John: Should transform() be required?

Steven: I think so

Leigh: I disagree
... all our modules should be optional
... and the ones that make it should be required
... By CR, if this has been implemented by enough implementations
... in the beginning, we thought we had to profile XPath, because some members objected to us requiring IEEE floats

Steven: I'm OK with schema validation being optional, because all forms still work
... but if transform() is optional then some forms won't work everywhere anymore

Leigh: All implementations have extensions
... if at least two vendors have an extension then it should be done the same way

John: I think requiring all implementations to have transform() is too heavy

<John_Boyer> I'd comment that there is a conformance level between optional and required called recommended

Steven: I'm OK with optional modules, just not saying it is a part of 1.2

<John_Boyer> Even if you got two interoperating implementations of this feature, that might escalate up from optional perhaps, but consider recommended rather than required

John: Uli mentions other transform languages

Leigh: I don't agree with the idea that 1.2 has to be all the features that are required
... that would prevent progress
... we should get consensus on features people want

Steven: I think we agree

<alain> Implementing all 1.2 features in XSLTForms will require time...

Steven: I just think we are discussing this in the wrong place

Leigh: I hope that the XPath 1.0/2.0 will go away

John: I think that XPath 2.0 will make it to the recommended level

Leigh: I'm glad to hear you say that
... but I think XSLT will be optional

John: I think we will get enough XPath 2.0 implementations to get it out of CR so it doesn't need to be optional

Leigh: I see this as valuable, even if in 2 years it is still optional

<John_Boyer> XPath 1.0 is required, XPath 2.0 should be optional or recommended, probably recommended

<John_Boyer> The transform function should be optional; maybe it should become recommended, but right now it can be added as an extension

<John_Boyer> so it is already an optional module

<klotz> http://www.w3.org/MarkUp/Forms/wiki/Transform

Nick: We need language to decide how we know if it is a string or a node

John: We want to support xslt for the present

Nick: We can say that the result is a string or a node and with xslt the difference is triggered by the output mode
... and mention that there can be other transformation languages

John: Not sure we have decided that there are more languages yet
... but if the transform doesn't understand the language or can't resolve the link, we need to say what happens

<scribe> ACTION: Nick to update the transform() wiki spec [recorded in http://www.w3.org/2010/11/02-forms-minutes.html#action01]

<trackbot> Created ACTION-645 - Update the transform() wiki spec [on Nick Van Den Bleeken - due 2010-11-09].

Leigh: Uli asked about XProc or XQuery

Uli: Do we limit the transform to xslt, or if we extend it, how do we identify it?

John: Mediatype of the link?

Uli: I agree

John: Do we specify that implementations MAY use other languages?

Leigh: We could make it a required function with no required transformation languages
... make everyone unhappy

John: [laughs]

Leigh: We could say it has no side effects
... You should be able to specify what type of mediatype it is

<unl> +1

Leigh: do we want to remove mention of XSLT except in examples?
... how do we pass variables?

<unl> Passing parameters/variables would be easier with an transform action ;)

<klotz> I see this at the top of the wiki page: {{#css:CSS/tr.css}}

Coffee

Leigh, we have assked for the CSS module to be implemented

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_First_Edition_Errata

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#Documentation_Conventions

<John_Boyer> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#ref-xhtml-1.0

<John_Boyer> [</nowiki>[[#ref-xhtml-1.0 |XHTML 1.0]]<nowiki>]</nowiki>

<John_Boyer> <specref ref="ref-xhtml-1.0"/>

<John_Boyer> XHTML, ODF or SVG

<John_Boyer> [XHTML 1.0], [ODF], or [SVG]

<John_Boyer> [[#ref-odf-1.1|ODF]]

<John_Boyer> [ODF]

<John_Boyer> ?

<John_Boyer> [[http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html ODF]]

<John_Boyer> Based on an action item, I've now added http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_First_Edition_Errata#Erratum_7:_Statement_of_Conformance_to_Informative_Schema

<klotz> http://www.mail-archive.com/wikibugs-l@lists.wikimedia.org/msg39858.html

<klotz> http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_in_Wiki#Core_Form_Controls

UI Events

Steven: Where did we get to?

John: We need to separate relevance and visibility
... relevance has been used to hide controls, and to describe non-selected cases in a switch
... and to describe what happens when binding to a non-existent node
... Eric needs a control-lifecycle

Eric: Well XForms is trying to define it.
... and there are use cases for it
... So any ideas on how to disentangle this?
... our proposal was not informed based on the last FtFs
... so what is the additional notion needed to break out of this impasse?

John: Thinking of <switch>
... we say "non-selected behaves as non-relevant"

Steven: Maybe we should move away from short cuts like that

John: For <group> you can style a non-relevant group as greyed out, but present, which doesn't happen with <switch>

Eric: And what happens to events is unclear too
... <switch> is a good example
... you want hidden cases alive but non-visible
... if something is non-relevant then handlers are not active
... both scenarios have a good rationale
... but you don't have a way of controlling which of the two are used

John: The more reliable the UI events become, the more likely we are to want to use them on controls in non-selected cases
... wizard-like cases, the user has gone through 3 of 5 steps, and they do something that invalidates an earlier step. Then there would be no invalid event that went to that control, so you can't listen to it.

Steven: Doesn't that mean that the step 3 control should show up the invalidation, not step 1?

Leigh: It cold be done with nonrelevant events that bubble up

Eric: We need a general solution for groups as well as cases

<John_Boyer> First, yes ideal world, but people create a lot of UIs that are not ideal. Also, people try to reuse the UI for "updates". So, they've already done the 5 step process, but now reenter the UI at step 3 and make a change where we need to tell them that they need to make a second change to step 5 in order to submit the update.

Steven: I've never met a wizard interface that you enter in the middle. Tabbed interfaces yes, but not wizards

<John_Boyer> Yes, the "wizard" interfaces do often have tabs attached to them too so that people can have the option to go to any step they want or just follow the next next next process if that's what they want

Eric: Relevance is not clear, is it the same as visibity

Steven: I think that visibility is a part of presentation, like being able to style negative numbers red
... relevance can influence visibility, but that doesn't mean that visibility is the same as relevance

Leigh: I think we need both sorts

<unl> nice article about hidden in html5: http://realtech.burningbird.net/web/html5/remove-hidden-attribute

[Discussion of whether visibility is presentation or not]

<John_Boyer> <bind nodeset> <property name="x" value="y"/>

Leigh: We need to fill in the exist/styling matrix

<klotz> 1. form control exists or not

<klotz> 2. form control is presented

<klotz> 3. form control gets events

<klotz> i think column 1 is redundant

<John_Boyer> "column"1 is facet 1; these aren't "columns" so much as orthogonal facets

<klotz> right

<John_Boyer> not exist == not presented && not receiving events

yes, but it is possible to have exist&not presented&not events

<John_Boyer> exist == not presented && receiving events || presented && not receiving events || presented && receiving events

<John_Boyer> Steven, yes this is what I tried to say that something could exist, e.g. is traversable to in a DOM, without being presented nor receiving events, but Leigh responded that it was not an independent facet *within* XForms

Right, implementation decision

<klotz> so I think presented/not and evented/not are independent and should be author-controllable in various situations, and we should examine that choice for a new MIP, for switch/case, for a predicate-like per-control option, and for controls not bound to nodes.

Leigh: Then we can define what switch means in terms of these aspects
... and we have a lot to discuss with respect to repeat

<John_Boyer> In current spec, I believe we uniformly chose that non-relevant is (presented && not receiving events) and relevant is (presented && receiving events), where "presented" means stylable, and the default styling of non-relevant happens to be invisible (or perhaps display none)

<John_Boyer> so the missing bits are (not presented and receiving events) and (not presented and not receiving events)

<John_Boyer> (not presented and receiving events) is the part about non-selected cases of switches still receiving events

<John_Boyer> (not presented and not receiving events) is the non-existence needed for the UI control lifecycle

Leigh: So we should try and see if we can do this with a MIP and one or two form control attributes
... and pick something that works

<John_Boyer> the 1.1 spec's non-relevant, i.e. presented and not receiving events, allows styling as non-visible, non-displayed, or displayed disabled

[ADJOURN]

Summary of Action Items

[NEW] ACTION: Nick to update the transform() wiki spec [recorded in http://www.w3.org/2010/11/02-forms-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/02 16:59:41 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ te / the /
Succeeded: s/feature/features/
Succeeded: s/John: I think that XPath 2.0 will make it to the required level/John: I think that XPath 2.0 will make it to the recommended level/
Succeeded: s/ss/s/
Succeeded: s/happends/happens/
Succeeded: s/sTEVEN/Steven/
Succeeded: i/John: Should transform() be required?/Topic: Transform (more)
Succeeded: s/specref/<specref/
Succeeded: s/style/cycle/
Succeeded: s/needs/is trying to define/
Succeeded: s/passe/passe?/
Succeeded: s/./>/
Succeeded: s/>/?/
Succeeded: s/widard/wizard/
Succeeded: s/I've/Steven: I've/
Succeeded: s/Wee/We/
Succeeded: s/ned/need/
Found Scribe: Steven
Inferring ScribeNick: Steven

WARNING: Replacing list of attendees.
Old list: unl Roseraie_2 John_Boyer
New list: Leigh_Klotz

Default Present: Roseraie_2, Leigh_Klotz, John_Boyer, unl, [IPcaller], ebruchez
Present: Nick Raman Uli John Jaehyuk(observer) Leigh Eric
Got date from IRC log name: 02 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/02-forms-minutes.html
People with action items: nick

[End of scribe.perl diagnostic output]