Forms WG FtF Day 1 -- 24 Mar 2010

<Steeeven> hi

<John_Boyer> hi

<klotz> OK net up but phone not yet

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

<Steven> hair: Steven, Leigh

Agenda bashing

<wiecha> Scribe: wiecha

1 line summary of each agenda item

rechartering looks good so far

Steven sending request to w3m with details for final approval

who to invite to join the WG?

we should list our preferred invited experts and talk with other companies soliciting participation

Test Suite agenda topic:

were going to do "bashing"

John: what does this entail?

Steven: create some tests

Nick: were some tests recently that we thought would go into new version of the test suite

UI events: Erik

Erik: at last F2F we had some agreement except Uli's objections on changes

in my opinion, would like to get closure on general concepts

toward future version of the spec

XML Events2

have a draft

taking further

who owns? Mark and???

shane

<nick> http://www.w3.org/MarkUp/Drafts/#xml-events2

<nick> http://www.w3.org/MarkUp/2008/ED-xml-events-20081223/

depending on Mark's role I (Steven) might take this over as I was an editor of version 1

JSON

need better extensibility for submission and respose handling

XPath 2.0

discussion of how/when to move to offering xpath 2.0 support

Erik: last discussion was around function signatures

might need more work

one question was whether signature of xforms xpath functions should be compatible with 1.0 or native 2.0

e.g. date function in 2.0 can return xsd date which is not in 1.0

Nick: both arguments and return types

downside is won't be backwards compatible

Erik: hard to say...don't have much experience

if you change sigs you'll have to rewrite. but you don't have to use 2.0

<scribe> new forms would hopefully start in 2.0

Steven: would declare at the top which version is being used

John: understood that 1.0 is required and 2.0 is recommended

Erik: would have to cast the strings into native types

Custom XPath: Erik

at last F2F followed up by contacting xslt wg sent to the list...we should review

Michael Kay also made recommendations based in Erik's questions...should review

can then complete draft spec already started

Node creation functions: Nick

did some work on the wiki

functions to create nodes from strings

<nick> http://www.w3.org/MarkUp/Forms/wiki/Node_%27create%27_functions

subtrees of XML from data

Components/patterns

could discuss some work on composite patterns such as master/detail and list to list

<nick> node creation functions : the discussion started when sequences were 'needed' for child content

is there an opportunity to simplify this

then package as components...which leads to the

XBL topic

Erik: not the answer for everything, solid base

should consider requirements for custom components

Steven: good approach, main approach is it's at odds with declarative nature

needs js

Erik: doesn't require JS

the way we use it the components are 100% XForms plus XBL, does not require JS

would be good to look at some examples in Orbeon

Nick: didn't take me long to write some custom components based on that approach

Variables: Erik

maybe naming is the issue to discuss

don't think we have spec ready text

Leigh: doesn't include AVTs

John: scope and lifetime are the big topics

closures etc

External models: have text to review

XForms for HTML

Leigh: would like to get agreement on scope for this doc

and then quick outline

Live documents: Steven

alter the document the form is in, e.g. tying class name to dependency graph

Erik: options could be special control

Map/Reduce support

make our constraints work on structure of instances as well as values

e.g. structural binds

<klotz> I am adding the one-liners to http://www.w3.org/MarkUp/Forms/wiki/FtF_2010_03_24_Agenda#Agenda

map/reduce are structural transforms

Leigh: what about controls for recursive or nested structures

e.g. trees

separate topic from map/reduce

Putting Control in Charge

@ref vs @nodeset vs @select

Erik: more general question of whether control is conceptually in charge of binding policy

vs. external attributes determining how control behaves

as implementor my impression is we can't escape control identity object which defines behavior

could name attributes however...

Errata...

<John_Boyer> links to two added above

Rechartering

HP and Adobe will be joining

Leigh: not sure about HP, has anyone talked with them?

John: they are doing interesting stuff with interactive docs and workflow...could be those folks

Steven: other candidates?

and for invited experts?

should invite Joern as expert

<nick> Alain Couthures

and Mark

and XRX folks

Kurt Cagle

Dan McCreary

EMC

AmpleSDK

Jadu

Atlassian

Nuxeo

Alfresco

Charlie: does it make sense to make better connection with the XML activity?

John: what's the benefit of being a separate activity just for XForms?

Steven: we could explore joining the XML coordination call

but moving the WG might be hard since the staff time there is very constrained now

John: is the ubi-web domain a better placement for forms?

Steven to explore joining the XML coord call, Leigh to participate if ok

response from XML CG: http://lists.w3.org/Archives/Public/public-forms/2010Mar/0030.html

<Steven> [back]

Errata

<John_Boyer> http://lists.w3.org/Archives/Public/public-forms/2010Mar/0027.html

The appearance attribute is not the same format as @class

does not take a space-separated list

Nick: what to do with conflicts?

e.g. minimal and full

John: right, could do that but it's really a hint

Erik: CSS handles conflicts with well-defined rules

John: right

CSS defines how to resolve conflicts

Steven: not really conflicts, just get applied in order

Erik: we'd have to specifiy

John: not really, it's a hint

Leigh: any QNames

John: yes

Leigh: thought we discussed this before and decided not to

Steven: changed the def to one of our and any number of others

Erik: not really a solution, can't say "minimal full"

are we happy to do that strict validation?

John: I'd be happy with just a space separated list...just pick the first one

Erik: or the last one

Leigh: so we could just restrict it to one of ours

John: now we've said you can only have one entry...what happens if you put multiple in now?

Nick: fails in Chiba

Leigh: if it's not defined it's undefined

Erik: doesn't this go against interop?

Steven: but interop is in terms of what's defined...rest is ok

Nick: could be confusing across multiple implementations

this is really a new feature, not an erratum

Leigh: but this shouldn't affect a conformance test

similar to loosening order for help, hint, alert

Nick: think it will be confusing

Erik: what are the use cases?

Leigh: two orthogonal things

John: an example in the email is minimal but also control what's shown when collapsed

e.g. full state/province names when pull down is open but abreviated codes when selection is done

Leigh: seeing lots of straight equality tests in existing code

John: so I could just use a foreign-namespaced attribute for now

if nobody is using this feature in 1.1 I'll do that

http://lists.w3.org/Archives/Public/public-forms/2010Mar/0028.html

what are implementors currently doing for these?

Erik: yes, we do encode these

John: spec is not clear

<ebruchez> http://www.w3.org/XML/2007/04/hrri/draft-walsh-tobin-hrri-00.html

<nick> http://www.w3.org/TR/xmlschema-2/#anyURI

Erik: there's also some work in HTML5 on this

John: I think XML schema is clear on what is valid URI

so we should be able to check for this

<nick> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators

so form authors could use actual spaces and form processor would encode

encoding is idempotent

Erik: right, we don't have to reinvent

browsers do this today for links input by users

John: yes, would apply for input values that are URLs

Erik: we now apply this only to @src, @schema, etc submission/resource but not in data

John: the internationalization wg also gave this feedback as last call to 1.1

related to IRIs

will increasingly be seen in URLs for asian sites as new characters are used

<ebruchez> got response from @ndw: HRRI came out as this note: http://www.w3.org/TR/2008/NOTE-leiri-20081103/

John: yes, there's some work to look at future versions, but what should we say about 1.1?

Erik: didn't think it was expected for 1.1

John: I did think it was

Erik: as form author I would expect it, but as implementor the spec is not clear

would be a step toward more user-friendliness

John: thought it was obvious

we encode the parameter phase

Erik: want to use leiri algorithm

Leigh: doesn't handle &

<Steven> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators

John: we could do this in a future version, but what about 1.1?

<Steven> "The Recommendation states that "it is impractical for processors to check that a value is a context-appropriate URI reference," thus freeing schema processors from having to validate the correctness of the URI."

<Steven> http://books.xmlschemata.org/relaxng/ch19-77009.html

Nck: ...examples of difficult encodings...

<nick> http://www.boe.org/my?url=boe?foo

Erik: seems clear that some type of encoding should take place but not sure exactly what

we don't know enough to resolve

<ebruchez> http://www.w3.org/html/wg/href/draft

<klotz> http://www.faqs.org/rfcs/rfc2368.html describes encoding of mailto:

<ebruchez> http://www.blackmesatech.com/2009/03/wah5/uricalc.html

John: we should either say we don't encode or point to a specific encoding policy we use

<nick> from 'Legacy extended IRIs for XML resource identification' Some productions are ambiguous. The "first-match-wins" (a.k.a. "greedy") algorithm applies. For details, see

Leigh: trying to encode when starting from a complete URL leads often to double encoding

<unl> hi steven

Leigh: which will often be the case when starting from user-provided data

John: for 1.1 the xlink encoding is the only reasonable one we have

Leigh: are you proposing this applies to calculated data as well? or just form text

John: applied at moment the URL is used...would not change instance data

nor the source document

get resource or src content and apply this encoding

Nick: if it's in the data w/dynamic URI this would apply

John: yes

<Steven> http://ab.גדהוזח.ij/kl/mn/op.html

So the erratum would clarify whether the content is used directly or first encoded in this specific way

<Steven> http://ab.دخح.جثت/ij/kl/mn/op.html

Erik: how does xlink relate to the leiri stuff?

John: i18n says anyuri is intended to be compatible

Steven: anyuri as lexical space which is what the user would expect.

John: right, e.g. an actual space character

so should actually work in the xforms processor

John: so should we issue a clarification that the anyURI encoding happens just before going over the wire?

Nick: nods

Steven: agree, would like an example of anyURI in lexical and value formats

Leigh: would like some test cases

John: yes, we have a few errata...should have a few tests for each one

Leigh: not clear there's even text associated with this...maybe a note

John: just a clarification

have seen implementations that don't do this encoding

so we ought to be saying something

Leigh: yes, but it's not a normative change

John: clarification not substantive erratum

Leigh: think we still need tests for double encoding problem

question marks etc

<Steven> http://dir.google.com/Top/World/Chinese_Simplified/%E8%AE%A1%E7%AE%97%E6%9C%BA/"

to be sure implementors aren't calling the wrong encoders

<Steven> http://dir.google.com/Top/World/Chinese_Simplified/计算机/

<Steven> Those two are equivalent

<klotz> just as long as it doesn't require this to decide when to encode: http://dir.google.com/Top/World/Chinese_Simplified/%E8%AE%A1%E7%AE%97%E6%9C%BA/%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD/

<unl> there's a trailing space in http://dir.google.com/Top/World/Chinese_Simplified/计算机/%22 ;)

Leigh: I suggest we check with Larry given he's coordinating IRI work

John: yes, if we're going into IRI space in future versions

Leigh: he wrote both of these RFCs

<scribe> ACTION: john_boyer to write up erratum text for encoding consistent with i18n and xlink recommendations [recorded in http://www.w3.org/2010/03/24-forms-minutes.html#action01]

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

<klotz> http://www.yelp.com/biz/indian-chili-cambridge

<raman> dinner plans?

<John_Boyer> Steven, can you rejoin the teleconference when you guys start?

<John_Boyer> Hi Steven, I rejoined a few minutes ago because it looked like you guys were back. But I am here and will join when you rejoin the teleconference

<unl> me too

<nick> scribe: nick

UI Events

<ebruchez> http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events#TOC-Proposal

Erik: Currently he UI events don't work in a way a form author could use them in a reliable way
... The current mechanism is based on a marking algorithm in the instance data
... For the form author the control shouldn't get a value-change event when the controls value doesn't change

<klotz> For components, could we have an element to express the desire to receive certain events such as MIP or value events?

Steven: When the value changes from 42 to 45 to .. and back to 42 you don't get an event

Erik: correct

wiecha: it should appear as a transaction between refreshes

ebruchez: if the control knows the old and new value, it is the best place to send the events

wiecha: it doesn't make a difference if the control or the control sends the events, the model can still do it

ebruchez: I think this shouldn't be specified by the spec (who sends the events)
... it simplifies the learning process for form authors (for value-change, read/write, relevant, required,...)
... explains how you could optimize when the bindings need to be updated

wiecha: it is a question if we want the model or the UI to do all the work

ebruchez: in our product it is something between the model and the UI
... it knows the bindings and the UI controls

klotz: do we think that the UI events are meant for the form author, and not for the implementation

ebruchez: so far I don't know an implementation that uses the UI events for controlling the controls

klotz: in custom-controls you also maybe want events to keep them up-to-date but you probably don't want the same UI events that could be cancelled by the form author.
... we should separately consider events that are used by form authors and events used by custom form controls
... I think we don't have enough experience with the events used by custom form controls
... does everybody agree?

ebruchez: I aggree

<unl> i agree with leigh

nick: also agree

(looks like the rest of the group silently agrees)

<unl> +q

unl: I also wants to be able to have model only processor

<klotz> So how about this "Res: For XForms 1.2, we will specify UI events designed for author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors."

ebruchez: this is another new feature, we have xxforms-value change which is similar to insert and delete events

klotz: do we need to check if the proposals make events in custom events hard

ebruchez: that will be hard, because then we have to look into custom controls

wiecha: if we see a red flag we should take it into account

Steven: does it change anything for the ordering of the events

ebruchez: currently we don't say anything about order

John_Boyer: it is also about the life-cycle of controls and controls in repeats

<klotz> So how about this "Res: For XForms 1.2, we will specify UI events designed for form author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors, and will make good-faith efforts not to impede that direction in the future."

RESOLUTION: For XForms 1.2, we will specify UI events designed for form author use, and will test for coverage and ease of use against use cases, and will separately consider the question of events for custom controls or model-only processors, and will make good-faith efforts not to impede that direction in the future.

<Steven_> Meeting Forms WG FtF Day 1

ebruchez: one distinction XForms has markup that specifies a control and at runtime we have instances of the controls (it becomes clearer in repeats, multiple runtime objects for one control in markup, even no runtime objects)
... If a control is created (runtime object), its value changes, MIPS changes, and then it can disappear, after it disappears no events can be send to the control nor can the user interact with the control

John_Boyer: we have text in the spec that you could style non-relevant controls

<unl> +q

John_Boyer: the controls can show what they last contained (and don't get events anymore)

wiecha: having an extra state in the life-cycle would be helpful

<John_Boyer> it isn't as easy as saying that a non-relevant control is simply not bound to a data node because an xf:input may only be non-relevant by virtue of being bound to a node whose relevant mip is false

wiecha: it looks like binding relevance to the lifetime of a control is a bit ...

unl: you want to keep state if a control becomes non-relevant

nick: you want not to keep state for non-relevant controls, so you don't have to keep all the non-relevant controls in memory

wiecha: same holds for non-selected cases in a switch

ebruchez: gives example of a huge form with a repeat
... we only have one relevance (can be triggered in multiple ways), and when not-relevant controls don't 'exist'

nick: a control should not keep state in my opinion

unl: I think that we should limit this

<unl> @nick: i didn't say something like that...

ebruchez: what state do we now have, MIPS comes from model, value too, repeat index, switch case and dialog state are the three that need to be serialized

<unl> my main point was that there's a difference between relevance and existence of a control

ebruchez: there is a need for a switch that remembers state for non-relevant cases

<John_Boyer> As an example of state, if you have a group that contains a switch on case #3, and the group becomes non-relevant, the contained switch will not maintain the state of being on case #3

<John_Boyer> repeat index is another example of state

klotz: did we ever tried model based repeat

<John_Boyer> the value being shown by the non-relevant control is another possible piece of state

ebruchez: there 'could' be two types of relevant, hard (when not pointing to a node), soft (when the node is not relevant)

<John_Boyer> There is language in current spec (could change) which says that a form author *could* style non-relevant controls as visible but disabled

klotz: what do you think of a minimized version of controls (and maybe have a model based version)

<John_Boyer> At which point, one might reasonably expect correct values will be shown even if xforms-value-changed is not dispatched

<unl> another example on relevance vs. existence: a repeat over a non-homogenous collection

John_Boyer: explains that when a control is not relevant the UI events could not be send to a control, nevertheless the control can update its value that is shown

wiecha: why can a non-relevant control track its value changes, when the model isn't calling the refresh anymore

ebruchez: I'marguing for a non-relevant control not keeping state

wiecha: Isn't there an outside agent that informs the control that it needs to be created and when it becomes non-relevant
... is the transition from relevant to non-relevant internally or externally driven?

ebruchez: That doesn't need to be specified
... it is up to implementers
... Concrete controls are created at the following times:

* During processing of the default action for xforms-model-construct-done event, if they meet the conditions for relevance

* When a new repeat iteration is inserted into a repeat container, if they meet the conditions for relevance

o either during xforms:insert processing

o or during refresh

* During refresh, when the condition for optimization goes from non-relevant to relevant

ebruchez: ...

John_Boyer: for repeat index there is an implicit instance that holds the index, an index() makes a dependency to the node

ebruchez: we don't have UI dependencies defined

John_Boyer: bcz. of the wording in the spec this will work now
... we have to do the same work for switch

ebruchez: the case() is only dependent on data in the data bound switch
... so it is only as complicated as repeat in the data bound switch case

John_Boyer: I'm currently working on the data driven switch

ebruchez: do we have consensus on controls don't keep state when not relevant

Steven: There are places where you see the non-relevant controls so you now you don't have fill it in

John_Boyer: what does it do with non-relevant groups, switches, repeats

ebruchez: you want to style it as disabled

John_Boyer: what happens to the switch when it is non-relevant
... If we don't keep state, it's appearance will be so strange, so we should be throw it out

Steven: gives use case again

John_Boyer: I agree, but then it should display accurate values.

ebruchez: We use the concept of read-only for it

nick: there is the use case where you don't want to submit the data, but want to show it disabled to the user

klotz: Is this a new MIP? Or just presentation

John_Boyer: If we allow custom MIPS we are done

Steven: There is conceptual difference between relevant and read-only

John_Boyer: some people don't want to see the form geometry to change when data becomes non-relevant

ebruchez: if we have a new MIP disabled, that is similar as relevant that would be fine

John_Boyer: we already can style it using the current MIPs and CSS

ebruchez: An implementation could style a control as disabled and displaying the latest value

John_Boyer: the control needs to know is position on the screen and how it affects the layout

ebruchez: you could take a snapshot, and forget everything, the only downside is when the switch becomes relevant again it 'forgets' the selected case

John_Boyer: we could introduce a new attribute that drives if we want to keep state if they become non-relevant

ebruchez: if you can put it on any control, and use inheritance
... we have such an attribute to say if non-selected cases be still there, and get all the events
... what do we do for input, if the input doesn't binds to a node (you have to remember the type, value,...)
... I see two ways

1) keep state: It will keep it state around when a control becomes non-relevant

2) keeps updating: It will keep it state around when a control becomes non-relevant, and update it's value -> but what if it's looses his binding

John_Boyer: in option 2, I think the value should be the empty string

ebruchez: in the switch case, you don't want to show the non selected cases, but you want the events to keep happening

<Steven_> [time for a break]

wiecha: We could say that is the control can choose how it behaves when non-relevant
... we need to define the control life cycle

John_Boyer: why don't the events enabled and disabled be sufficient?

ebruchez: but then a control needs to be still alive in some cases when the control becomes disabled

<John_Boyer> as said in meeting, it's not "adding" complexity to maintain the feature in which non-relevant controls are capable of remembering their state in case they are styled as visible but disabled

<John_Boyer> more (but necessary) complexity is being added to support the feature of UI controls *not* remembering state because this allows significant optimization (and may even become the default)

<John_Boyer> But the ability to remember state is needed to continue to support a feature we already have that is in use, and an XForms processor would still need to support that in case the author explicitly requests version="1.1" processing

<Steven_> [back]

<Steven_> scribe: Steven

<Steven_> Steven: Can we wrap this?

<Steven_> John: Are we trying to remove features we already have?

<Steven_> Erik: They are useful, so we should retain the functionality

<Steven_> ... the main use case that has questioned the proposed lifestyle, is visible but disabled

<Steven_> John: and b) Even if visible showing what is going on

<Steven_> ... in 1.1 that is what happens

<Steven_> ... we detach the event handlers, but don't block the updating

<Steven_> ... now we are considering more optimised behaviours

<Steven_> Erik: The visible behaviour is not *required* by the spec

<Steven_> ... we don't specify it fully

<Steven_> John: Yes we do

<Steven_> Erik: It is not as clear as some other features

<Steven_> John: It's a classic misunderstanding

<Steven_> Erik: I wouldn't have inferred that

<Steven_> John: In repeats nodes are responsive to the node they are bound to

<Steven_> ... even if in a non-relevant group

<Steven_> ... all we do is unhook events

<Steven_> ... there are interesting side-effects

<Steven_> ... if a group becomes non-relevant, the events become unhooked and the controls are unavailable

<Steven_> ... but if a binding becomes empty, that has a bigger effect

<Steven_> Erik: It doesn't follow if you have variables, or if you use XPath 2

<Steven_> John: It is either inheritance or the root element node of the instance

<Steven_> ... if you have more interesting way? of geting context, there would be less egregious consequences if a group became non-relevant because of an empty nodeset

<Steven_> ... but if it becomes non-relevant because of a relevance mip, then it still provides context

<Steven_> Erik: Something is missing

<Steven_> ... when can a control be destroyed?

<Steven_> .... disappearing repeat iterattions

<Steven_> ... but non-relevance is not enoug

<Steven_> Erik: So we need new events

<Steven_> Erik: We are adding new concepts here

<Steven_> John: To support the case of knowing when the objects are created and destroyed for optimization purposes

<Steven_> Steven: Isn't that an implementation detail?

<Steven_> Erik: It is not purely for relevance

<Steven_> ... you can't do the optimisation if the controls are required to do things

<Steven_> ... you can do it in implementations that only do disply:none for non-relevance

<Steven_> s/disply/display/

<Steven_> John: In a group of controls where a payment method has been selected, they make a choice, a change event happens, and a toggle switches on details for thatt method

<Steven_> ... but then they go and do something they didn't mean, and so the payment details become non-relevant

<Steven_> ... and they switch it back, undoing the msitake

<Steven_> ... the controls become relevant again

<Steven_> Steven: You don't destroy the instance values

<Steven_> John: Yes, but switch has selected case 2, you want to keep that

<Steven_> Leigh: In forms 1.2 we can use select @ref

<Steven_> Erik: We agree that there are valiid use cases

<Steven_> s/ii/i/

<Steven_> Erik for both ways

<Steven_> ... some push towards controls not keeping state

<Steven_> John: Even that being default

<Steven_> Erik: ANd for the opposite

<Steven_> s/AN/An/

<Steven_> Erik: So what's the next step

<Steven_> Steven: We're designing XForms 1.2, so let's use model-ased switching#

<Steven_> s/-ased/-based

<Steven_> John: Another use case, data-processing, heads-down data entry, where you don;t want the layout to change

<Steven_> John: so do value changes need to be tracked?

<Steven_> ... some expect it, and would file bug reports

<Steven_> Leigh: Yes

<Steven_> ... that was my point earlier

<Steven_> John: We have three responses to non-relevance 1 display: none, 2. display: hidden 3. Disabbled

<Steven_> Leigh: How is disabled different from read-only

<Steven_> John: Events

klotz: maybe we need prune, instead of relevance and disabled

John_Boyer: we have a use case, and solved it by styling non-relevant, maybe we need to throw it out

klotz: maybe we need both MIPS prune and read-only

John_Boyer: we could throw out styling on non-relevant
... we don't need prune at the data layer, we already have relevance at the data layer
... if a control can say that relevance applies to the control

ebruchez: if you do that how you are going to style it if the control binds to non-relevant data

John_Boyer: we're back to keep-state, bcz. we want the control some kind of alive
... the default could be not there when non-relevant, another level could still there but disabled
...

ebruchez: in that case should the control dispatch xforms-disabled when it doesn't consumes the relevance property
... otherwise we need another event
... we could add an extra MIP

John_Boyer: I don't like us adding an extra MIP that does almost the same as relevant

ebruchez: in some cases you want the read-only data to be pruned in other cases you wan't
... we are picking real specific cases, and no general cases

John_Boyer: if you want to style non-relevant controls you need to keep state

wiecha: if we ditch the feature it simplifies the life-cycle of the control

ebruchez: how do we prune read-only nodes (if required) OR how do we style non-relevant nodes

John_Boyer: if we drop the functionality, do we drop important use cases?

ebruchez: I think giving multiple meanings to relevance makes it complex

Steven: the true thing is your saying that it is non-relevant

ebruchez: relevance is a tool for hiding stuff, and disabling event-handlers

Steven: If you say that relevance is misused for presentation issues then we need to look into that

- DRAFT -

Forms WG FtF Day 1

24 Mar 2010

Attendees

Contents

Agenda bashing

Rechartering

Errata

UI Events

Summary of Action Items

Scribe.perl diagnostic output