See also: IRC log
<scribe> Chair: Steven
<scribe> Scribe: Steven
[Morning session, spec hacking and other action items]
<unl> http://www.sklar.com/badgerfish/
[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
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>
<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
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
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¬ presented¬ 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]
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]