Forms WG Face-to-Face Meeting -- 06 Nov 2009

<nvdbleek> John_Boyer: what about the second attribute

<nvdbleek> nvdbleek: it is a node set and the nodes get added to the newly created node, the nodeset can contain attributes and nodes (text, or other elements)

<nvdbleek> John_Boyer: what about the order of the child elements

<nvdbleek> nvdbleek: Like said before, in XPath 1.0 it is document order, which is not defined in XPath 1.0, so it could be implementation defined

<nvdbleek> ebruchez: [presents an example of the why you want to create complex content]

<klotz> http://www.ibm.com/developerworks/java/library/j-jdom/

<nvdbleek> nvdbleek: you don't want to do this because then you can change the instance data, and this breaks the assertions needed by our custom functions. And XPath is designed to work on an immutable document

<nvdbleek> John_Boyer: We should note this in our spec, otherwise people reading the spec wouldn't know why we did it this way

<nvdbleek> nvdbleek: agreed, it is important that we keep our data model unmutable during the evaluation of an XPath expression

<nvdbleek> John_Boyer: Shouldn't we add serialize if we have parse

<nvdbleek> nvdbleek: OK

<nvdbleek> ebruchez: An example is an textarea that stores it in string in the instance and wants to parse that XML

<nvdbleek> Steven: I would like to have a second parameter that is the grammar

<klotz> mkay on using XSLT2 to parse arbitrary string grammars: http://www.saxonica.com/papers/ideadb-1.1/mhk-paper.xml

<nvdbleek> John_Boyer: Serialize options: should it prune non-relevance?

<nvdbleek> ebruchez: the serialize function is more light way, then submission. But the serialize function can use the same mechanism of submission

<John_Boyer> Leigh: xforms-submit-serialize?

<nvdbleek> John_Boyer: We need a lot of parameters on the serialize

<John_Boyer> John: Right now xforms-submit-serialize doesn't include submission data in the event context.

<nvdbleek> ebruchez: We could let the second parameter let it point to an element simular to the submission element

<nvdbleek> John_Boyer: the parse will only parse a subset (no dtd,..)

<John_Boyer> Does parse() have to resolve any URLs?

<nvdbleek> unl: it could be a security issue that the entity references are resolved during parsing

<nvdbleek> nvdbleek: we already have this with submission and load

<nvdbleek> ebruchez: yes submission returns XML

<nvdbleek> nvdbleek: we have the doc() in XPath 2.0, here you can parse an arbitrary XML

<nvdbleek> nvdbleek: a processor can decide not to let doc() parse the XML, parse() could also not resolve uri's

<nvdbleek> ebruchez: we validate the data that is entered when filling in the form

there's a subtle but important difference: as a form author you can control what resources are accessed through xf:submission, xf:load, or fn:doc(), but can never control what a user types into a textarea (whose content is then passed to fn:parse())

<nvdbleek> nvdbleek: you CAN control what is passed to the parse function by first checking the input passed the parse function

<John_Boyer> seems we should be saying whether all occurrences of parsing currently performed by XForms processor (e.g. instance/@src and submission results) should resolve external URLs

<John_Boyer> I had always assumed (for security) that the null url resolver was used

<John_Boyer> <xf:submission ... ><xf:resource value="some/data"> ... </xf:submission> <xf:input ref="some/data"> ...

<nvdbleek> unl: we should look at submission and instance

<nvdbleek> John_Boyer: If we could provide the grammer as a paramater

<nvdbleek> John_Boyer: then we could support JSON,...

<John_Boyer> parse as json and serialize as json gets json interaction while still having the xml at the core

<nvdbleek> nvdbleek: With a constant to identify it would be easier for the author

unl: this should be a IANA-registered media-type

<nvdbleek> ebruchez: element() and attribute() are more important then parse()

<klotz> xslt2 json transformation http://www.bramstein.com/projects/xsltjson/ including "Badgerfish" convention (round trip)

<ebruchez> parser=new DOMParser(); xmlDoc=parser.parseFromString(text,"text/xml");

<ebruchez> "For security reasons, modern browsers do not allow access across domains."

<nvdbleek> John_Boyer: We will have a Module element() and attribute() and another module with parse and serialize

<nvdbleek> nvdbleek: We should handle dynamic error in a recoveral way

<klotz> xslt2 json transformation http://www.bramstein.com/projects/xsltjson/ including "Badgerfish" convention (round trip)

<nvdbleek> nvdbleek: shouldn't it be a cancelable error event

<John_Boyer> well, I think that the above is written from the standpoint of data that starts life as XML, becomes JSON, then possibly you want to get it back to XML

<John_Boyer> But it is more important, for us, to consider connectivity, i.e. connecting to a json data source

<John_Boyer> So the data starts life as json, we import to XML for Xforms processing, then convert back to json for return to a service.

<John_Boyer> adjourn for today

<John_Boyer> rrsgagent, make minutes

<John_Boyer> Date: 06 Nov 2009

<John_Boyer> scribe: ebruchez

Rechartering

Steven: Defining our mission for the new charter.

John: Are we doing "XML apps on the web" rather than just forms? Our focus on XML is clear.

Erik: The term "XML application" is confusing: taken as XML vocabulary by some, and even so it is unclear.

Leigh: I would just describe the layers: data, logic, and UI.

John: Submission is the most powerful thing we have. How do we reflect that?
... We agree on less f2f meetings, but we could prefer extended ones like this one (4 days).

Erik: I don't like the term "next generation". It's just a claim.

Leigh: Let's just focus on the bullet points.

John: Do we actually "monitor" implementations?

Steven: I think it would be good to do more there.

Steven & all: (discussing charter items)

John: Between LC and CR, XForms 1.0 took 11 months. XForms 1.1 took 10 months.
... What is a realistic timeline for XForms 2.0 given our history?

<Steven> CR to PR on XForms 1.1 was 20 months

John: So we plan to get to LC of XForms 2.0 within the timeframe.
... We could look at March 2010 as a deadline: whatever features are in FPWD by that date will be in 1.2.

Leigh: What about unpublishing 1.2 modules from 1.1. E.g. XForms 1.2 has an XPath module. We would republish 1.1 without those modules that have been taken out.

Nick: ...

John: No issue: we would say the XPath 2.0 support module is optional.

Erik: Problem solved by this approach?

Leigh: We need an 1.2 core document. When we are done publishing 1.2 modules, we produce 1.2 core by subtracting what's in the modules.

Erik: Good as long as we don't unnecessarily try to modularize, since our experiencen the past has shown that was too time-consuming.

John: We do opportunistic modularization.

Steven: How many LC comments for 1.1?

John: 144, and we did over 160 diffs to the spec.

Leigh: In the timeline, let's talk about XForms 1.2 Modules to clarify.

Steven: For CR -> PR, let's look at 1.1 history. So 9 months.
... We might need a requirements doc for 2.0.

John: What about 1.2?

Erik: It's just rather small stuff implementors want to see standardized.

Steven: It was the same for 1.1.

Nick: If we start with a wiki page for the requirements, I am happy to convert that to specxml.
... We should add XSLT working group for XPath feedback.

All: (Discussing liaison with other W3C groups)

John: Voice guy said interesting stuff about the notion of focus. Not sure if that has impact on us.

Steven: XML Events comes to us.

All: Reviewing rest of charter proposal.

John: We need to add a timeline for XML Events 2.
... XForms 1.2 would rely on XML Events 2, right?

<John_Boyer> http://www.w3.org/MarkUp/Forms/2009/charter2010.html

<Steven> http://www.w3.org/MarkUp/Forms/2009/charter2010.html

<klotz> +1

<John_Boyer> +1

<Steven> +1

<nick> +1

<unl> +1

RESOLUTION: Submit recharter document at http://www.w3.org/MarkUp/Forms/2009/charter2010.html

<Steven> Yay!

<John_Boyer> break for lunch

<John_Boyer> scribe: Uli

<John_Boyer> scribenick: unl

New Features

John_Boyer: what would you like to talk about?
... submission targeting?
... architectural mismatch of ui events?

unl: optional model?

nvdbleek: events would be good topic

John_Boyer: there seems to be implementation experience already
... we should also fix some problems in new dot releases instead of solely adding new features

UI Events

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

Erik: *explains the problems he found during implementation of ui events*
... processing model is confusing for form authors
... e.g., getting xforms-value-changed even if the value didn't change and vice versa

John_Boyer: even more confusing for xforms-invalid and friends

Erik: just want to have xforms-value-changed when the value of the control changed, etc.

John_Boyer: do you expect another xforms-invalid event for a control changing value, which is already invalid?

ebruchez: no

unl: no

John_Boyer: maybe adding mip status information to event context info helps

<John_Boyer> events like invalid happen on startup on form

<John_Boyer> Erik discussing how UI events could be different

<John_Boyer> Erik: xforms-enabled/xforms-disabled event should happen before any other

<John_Boyer> ebruchez: control lifecycle is bracketed by xforms-enabled and xforms-disabled

<John_Boyer> so disabled should be last

<John_Boyer> and enabled should be first

ebruchez: all other mips have sensible defaults, so events upon init happen only if a value differs from default

John_Boyer: so a control being inserted into a repeat first receives xforms-enabled?

ebruchez: yes

<John_Boyer> ebruchez: context info receives iteration numbers for all repeats in which a control is nested

<John_Boyer> http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-repeat-processing

ebruchez: three root causes for control creation: initial creation, repeat insert, change to relevant
... non-default mip events are dispatched, xforms-value-changed apparently not

<John_Boyer> on initialization, why not just have xforms-enabled and use context info for the remaining MIP info

all: *discuss non-relevance issues*

klotz: are non-relevant select-items still able to respond to hint?

<John_Boyer> ebruchez: for a non-relevant control, it won't get an initial xforms-disabled because it is as if it does not exist to the form author

<John_Boyer> We were trying to avoid having form author ephemeral messages from displaying on startup in response to xforms-invalid messages

<John_Boyer> if the initial xforms-enabled simply indicated valid or not in context info, then that would work

<John_Boyer> Uli: I think there should be an xforms-invalid on initialization

<John_Boyer> Uli: The default on init is valid

<John_Boyer> Leigh: You need a function you can call on the control that tells whether the control is in the initial state or whether the user has changed the value

<John_Boyer> Uli: Not against context info in each of the MIP events, just against omitting xforms-invalid event dispatch because some other event e.g. xforms-enabled, has validity MIP info

<John_Boyer> ebruchez: controls update their mips and value, and then the events are dispatched to the control

unl: first thing is: controls maintain their state, then we can figure out how events are supposed to work

John_Boyer: which state do they maintain in case of inherited non-relevance?

ebruchez/unl: the computed state

John_Boyer: we need more event context information then
... wonder what that might be

<John_Boyer> scribe: John_Boyer

Seems the context info for the events leading up to xforms-disabled (in destruction case) should have relevant bit set off, and relevant bit should represent control relevance, not just data relevance

Leigh: there is no law of excluded middle. A non-relevant control could be neither valid or invalid

Erik: if you have a control that has received xforms-invalid, and then it receives xforms-disabled, and then later it receives xforms-enabled plus xforms-invalid, then it has received xforms-invalid twice
... We seem to need to listen for xforms-disabled to remove a control from an "invalid" list

Nick: If you receive xforms-enabled with context info on validity, but not xforms-invalid event, then that synchronizes with something becoming xforms-disabled then xforms-enabled again.
... The form author listens for enabled/disabled for validity tracking on create/destroy, and listen for xforms-valid/xforms-invalid for state change during the lifetime of the form.

Uli: I think it is confusing for form authors to listen for enabled/disabled for validity. I think the controls validity state should be reused when it becomes relevant again.

Nick: If you have a repeat with 5 rows, then the parent becomes non-relevant, the repeat stops updating
... so then node insertions or deletions may change what the repeat operates over, but the repeat isn't operating over it because it is non-relevant

Need to choose from among the following:

1) On enable/disable, context info contains valid/invalid info

2) On enable, xforms-invalid dispatched if needed, and on disable, xforms-valid gets dispatched even if control *was* bound to an invalid node

In case #1, the form author has to listen to enable/disable as part of tracking valid/invalid controls

In case #2, the form author only listens to valid/invalid events for tracking valid/invalid controls, but when a control becomes disabled, it receives a valid event even if it *was* bound to an invalid node

<ebruchez> John/Leigh/Nick: If the control is non-relevant, we don't have to say it's valid, therefore we don't have to send an xforms-valid event when the control is about to become non-relevant.

John: On xforms-disabled, we actually don't need MIP context info because it doesn't apply anymore.

<trackbot> Created ACTION-580 - Send an email to the group to summarize the discussion on UI events so far. [on Erik Bruchez - due 2009-11-14].

- DRAFT -

Forms WG Face-to-Face Meeting

06 Nov 2009

Attendees

Contents

Rechartering

New Features

UI Events

Summary of Action Items

Scribe.perl diagnostic output