00:02:01 <nvdbleek> John_Boyer: what about the second attribute
00:03:01 <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)
00:03:25 <nvdbleek> nvdbleek has joined #forms
00:03:53 <nvdbleek> John_Boyer: what about the order of the child elements
00:04:31 <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
00:04:40 <klotz> klotz has joined #forms
00:08:54 <nvdbleek> ebruchez: [presents an example of the why you want to create complex content]
00:11:37 <klotz> http://www.ibm.com/developerworks/java/library/j-jdom/
00:12:08 <Zakim> Zakim has left #forms
00:16:04 <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
00:18:52 <nvdbleek> John_Boyer: We should note this in our spec, otherwise people reading the spec wouldn't know why we did it this way
00:19:54 <nvdbleek> nvdbleek: aggreed, it is important that we keep our data model unmutable during the evaluation of an XPath expression
00:23:44 <nvdbleek> John_Boyer: Shouldn't we add serialize if we have parse
00:23:56 <nvdbleek> nvdbleek: OK
00:24:16 <Steven> s/aggr/agr/
00:32:00 <nvdbleek> ebruchez: An example is an textarea that stores it in string in the instance and wants to parse that XML
00:36:47 <nvdbleek> Steven: I would like to have a second parameter that is the grammer
00:41:43 <klotz> mkay on using XSLT2 to parse arbitrary string grammars: http://www.saxonica.com/papers/ideadb-1.1/mhk-paper.xml
00:41:57 <klotz> s/grammer/grammar/
00:47:02 <nvdbleek> John_Boyer: Serialize options: should it prune non-relevance?
00:49:24 <nvdbleek> ebruchez: the serialize function is more light way, then submission. But the serialize function can use the same mechanism of submission
00:50:01 <John_Boyer> Leigh: xforms-submit-serialize?
00:50:05 <nvdbleek> John_Boyer: We need a lot of parameters on the serialize
00:50:37 <John_Boyer> John: Right now xforms-submit-serialize doesn't include submission data in the event context.
00:50:51 <nvdbleek> ebruchez: We could let the second parameter let it point to an element simular to the submission element
00:51:55 <nvdbleek> John_Boyer: the parse will only parse a subset (dtd,..)
00:52:02 <John_Boyer> Does parse() have to resolve any URLs?
00:52:15 <nvdbleek> s/dtd/no dtd/
00:53:40 <nvdbleek> unl: it could be a security issue that the entity references are resolved during parsing
00:56:22 <nvdbleek> nvdbleek: we already have this with submission and load
00:56:57 <nvdbleek> ebruchez: yes submission returns XML
01:03:49 <nvdbleek> nvdbleek: we have the doc() in XPath 2.0, here you can parse an arbitrary XML
01:05:17 <nvdbleek> nvdbleek: a processor can decide not to let doc() parse the XML, parse() could also not resolve uri's
01:05:55 <nvdbleek> ebruchez: we validate the data that is entered when filling in the form
01:06:47 <unl> 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())
01:15:59 <nvdbleek> nvdbleek: you CAN control what is passed to the parse function by first checking the input passed the parse function
01:16:54 <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
01:17:18 <John_Boyer> I had always assumed (for security) that the null url resolver was used
01:19:21 <John_Boyer> <xf:submission ... ><xf:resource value="some/data"> ... </xf:submission> <xf:input ref="some/data"> ...
01:21:15 <klotz> klotz has joined #forms
01:27:03 <nvdbleek> unl: we should look at submission and instance 
01:27:33 <nvdbleek> John_Boyer: If we could provide the grammer as a paramater
01:27:48 <nvdbleek> John_Boyer: then we could support JSON,...
01:28:46 <John_Boyer> parse as json and serialize as json gets json interaction while still having the xml at the core
01:28:49 <nvdbleek> nvdbleek: With a constant to identify it would be easier for the author
01:30:15 <unl> unl: this should be a IANA-registered media-type
01:31:05 <nvdbleek> ebruchez: element() and attribute() are more important then parse()
01:31:21 <klotz> klotz has joined #forms
01:32:24 <klotz> xslt2 json transformation http://www.bramstein.com/projects/xsltjson/ including "Badgerfish" convention (round trip)
01:32:34 <ebruchez> parser=new DOMParser();   xmlDoc=parser.parseFromString(text,"text/xml");
01:33:19 <ebruchez> "For security reasons, modern browsers do not allow access across domains."
01:41:50 <nvdbleek> John_Boyer: We will have a Module element() and attribute() and another module with parse and serialize
01:42:47 <nvdbleek> nvdbleek: We should handle dynamic error in a recoveral way
01:43:34 <klotz> xslt2 json transformation http://www.bramstein.com/projects/xsltjson/ including "Badgerfish" convention (round trip)
01:45:49 <nvdbleek> nvdbleek: shouldn't it be a cancelable error event
01:55:45 <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
01:56:20 <John_Boyer> But it is more important, for us, to consider connectivity, i.e. connecting to a json data source
01:56:42 <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.
01:56:59 <John_Boyer> adjourn for today
01:57:04 <John_Boyer> rrsgagent, make minutes
01:57:10 <John_Boyer> rrsagent, bye
01:57:10 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2009/11/05-forms-actions.rdf :
01:57:10 <RRSAgent> ACTION: Charlie to write the module for 'import with src/resource for model-only content resolved once during model-construct with error on cyclic import as a direct child of model' [1]
01:57:10 <RRSAgent>   recorded in http://www.w3.org/2009/11/05-forms-irc#T22-47-19
16:58:50 <RRSAgent> RRSAgent has joined #forms
16:58:50 <RRSAgent> logging to http://www.w3.org/2009/11/06-forms-irc
16:58:55 <John_Boyer> rrsagent, make log public
16:59:49 <John_Boyer> Agenda: http://www.w3.org/MarkUp/Forms/wiki/FtF_2009_11_Palo_Alto_Agenda
16:59:54 <John_Boyer> Chair: John
17:00:02 <John_Boyer> Date: 06 Nov 2009
17:00:30 <John_Boyer> Meeting: Forms WG Face-to-Face Meeting
17:00:41 <John_Boyer> Regrets: Charlie
17:00:54 <klotz> klotz has joined #forms
17:02:44 <unl> unl has joined #forms
17:09:09 <Steven> Steven has joined #forms
17:10:32 <klotz> klotz has joined #forms
17:10:55 <ebruchez> ebruchez has joined #forms
17:12:00 <John_Boyer> scribe: ebruchez
17:12:04 <ebruchez> Topic: Rechartering
17:15:23 <ebruchez> Steven: Defining our mission for the new charter.
17:17:16 <ebruchez> John: Are we doing "XML apps on the web" rather than just forms? Our focus on XML is clear.
17:17:22 <nvdbleek> nvdbleek has joined #forms
17:18:36 <ebruchez> Erik: The term "XML application" is confusing: taken as XML vocabulary by some, and even so it is unclear.
17:19:18 <ebruchez> Leigh: I would just describe the layers: data, logic, and UI.
17:20:04 <ebruchez> John: Submission is the most powerful thing we have. How do we reflect that?
17:23:20 <ebruchez> John: We agree on less f2f meetings, but we could prefer extended ones like this one (4 days).
17:28:11 <ebruchez> Erik: I don't like the term "next generation". It's just a claim.
17:30:38 <ebruchez> Leigh: Let's just focus on the bullet points.
17:36:08 <ebruchez> John: Do we actually "monitor" implementations?
17:36:21 <ebruchez> Steven: I think it would be good to do more there.
17:37:04 <markbirbeck> markbirbeck has joined #forms
17:44:05 <ebruchez> Steven & all: (discussing charter items)
17:47:30 <ebruchez> John: Between LC and CR, XForms 1.0 took 11 months. XForms 1.1 took 10 months.
17:49:24 <ebruchez> John: What is a realistic timeline for XForms 2.0 given our history?
17:51:32 <Steven> CR to PR on XForms 1.1 was 20 months
17:51:52 <klotz> klotz has joined #forms
17:51:53 <ebruchez> John: So we plan to get to LC of XForms 2.0 within the timeframe.
17:57:09 <ebruchez> John: We could look at March 2010 as a deadline: whatever features are in FPWD by that date will be in 1.2.
17:58:34 <ebruchez> 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.
17:59:11 <ebruchez> Nick: ...
17:59:30 <ebruchez> John: No issue: we would say the XPath 2.0 support module is optional.
17:59:51 <unl> unl has joined #forms
18:01:24 <ebruchez> Erik: Problem solved by this approach?
18:04:42 <ebruchez> 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.
18:05:06 <ebruchez> Erik: Good as long as we don't unnecessarily try to modularize, since our experiencen the past has shown that was too time-consuming.
18:05:16 <ebruchez> John: We do opportunistic modularization.
18:06:04 <ebruchez> Steven: How many LC comments for 1.1?
18:06:17 <ebruchez> John: 144, and we did over 160 diffs to the spec.
18:07:05 <ebruchez> Leigh: In the timeline, let's talk about XForms 1.2 Modules to clarify.
18:08:46 <ebruchez> Steven: For CR -> PR, let's look at 1.1 history. So 9 months.
18:11:20 <ebruchez> Steven: We might need a requirements doc for 2.0.
18:11:24 <ebruchez> John: What about 1.2?
18:11:39 <ebruchez> Erik: It's just rather small stuff implementors want to see standardized.
18:11:47 <ebruchez> Steven: It was the same for 1.1.
18:12:40 <klotz> klotz has joined #forms
18:16:55 <ebruchez> Nick: If we start with a wiki page for the requirements, I am happy to convert that to specxml.
18:19:58 <ebruchez> Nick: We should add XSLT working group for XPath feedback.
18:38:54 <unl> unl has joined #forms
19:04:33 <ebruchez> All: (Discussing liaison with other W3C groups)
19:07:09 <ebruchez> John: Voice guy said interesting stuff about the notion of focus. Not sure if that has impact on us.
19:08:25 <ebruchez> Steven: XML Events comes to us.
19:22:06 <ebruchez> All: Reviewing rest of charter proposal.
19:31:08 <ebruchez> John: We need to add a timeline for XML Events 2.
19:32:50 <ebruchez> John: XForms 1.2 would rely on XML Events 2, right?
19:37:49 <John_Boyer> http://www.w3.org/MarkUp/Forms/2009/charter2010.html
19:37:56 <Steven> Steven has joined #forms
19:38:09 <Steven> http://www.w3.org/MarkUp/Forms/2009/charter2010.html
19:42:36 <ebruchez> ebruchez has joined #forms
19:45:46 <klotz> +1
19:45:50 <John_Boyer> +1
19:45:56 <Steven> +1
19:45:56 <ebruchez> +1
19:46:05 <nick> +1
19:46:37 <unl> +1
19:47:23 <ebruchez> RESOLUTION: Submit recharter document at http://www.w3.org/MarkUp/Forms/2009/charter2010.html
19:49:55 <Steven> Yay!
19:51:18 <John_Boyer> break for lunch
21:26:08 <John_Boyer> John_Boyer has joined #forms
21:26:19 <John_Boyer> rrsagent, make minutes
21:26:19 <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/06-forms-minutes.html John_Boyer
21:27:17 <unl> unl has joined #forms
21:29:13 <nvdbleek> nvdbleek has joined #forms
21:29:24 <John_Boyer> scribe: Uli
21:29:29 <John_Boyer> scribenick: unl
21:29:48 <unl> Topic: New Features
21:30:11 <unl> John_Boyer: what would you like to talk about?
21:30:19 <unl> ... submission targeting?
21:30:34 <unl> ... architectural mismatch of ui events?
21:30:53 <unl> unl: optional model?
21:31:16 <unl> nvdbleek: events would be good topic
21:31:46 <unl> John_Boyer: there seems to be implementation experience already
21:32:39 <unl> ... we should also fix some problems in new dot releases instead of solely adding new features
21:32:55 <unl> Topic: UI Events
21:33:18 <ebruchez> ebruchez has joined #forms
21:33:21 <ebruchez> http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events
21:34:31 <unl> Erik: *explains the problems he found during implementation of ui events*
21:36:08 <unl> ... processing model is confusing for form authors
21:36:48 <unl> ... e.g., getting xforms-value-changed even if the value didn't change and vice versa
21:37:18 <unl> John_Boyer: even more confusing for xforms-invalid and friends
21:38:03 <unl> Erik: just want to have xforms-value-changed when the value of the control changed, etc.
21:42:26 <unl> John_Boyer: do you expect another xforms-invalid event for a control changing value, which is already invalid?
21:42:30 <unl> Erik: no
21:42:37 <unl> unl: no
21:42:50 <unl> s/Erik:/ebruchez:/
21:47:48 <unl> John_Boyer: maybe adding mip status information to event context info helps
21:51:37 <John_Boyer> events like invalid happen on startup on form
21:52:09 <John_Boyer> Erik discussing how UI events could be different
21:52:44 <John_Boyer> Erik: xforms-enabled/xforms-disabled event should happen before any other
21:53:35 <John_Boyer> Erik: control lifecycle is bracketed by xforms-enabled and xforms-disabled
21:53:41 <John_Boyer> so disabled should be last
21:53:46 <John_Boyer> and enabled should be first
21:53:59 <unl> s/Erik:/ebruchez:/
21:55:13 <unl> ebruchez: all other mips have sensible defaults, so events upon init happen only if a value differs from default
21:55:47 <unl> John_Boyer: so a control being inserted into a repeat first receives xforms-enabled?
21:55:55 <unl> ebruchez: yes
21:57:41 <John_Boyer> ebruchez: context info receives iteration numbers for all repeats in which a control is nested
22:06:23 <John_Boyer> http://www.w3.org/TR/2009/REC-xforms-20091020/#ui-repeat-processing
22:07:44 <unl> ebruchez: three root causes for control creation: initial creation, repeat insert, change to relevant 
22:09:07 <unl> ... non-default mip events are dispatched, xforms-value-changed apparently not
22:10:30 <John_Boyer> on initialization, why not just have xforms-enabled and use context info for the remaining MIP info
22:18:33 <unl> all: *discuss non-relevance issues*
22:21:47 <unl> klotz: are non-relevant select-items still able to respond to hint?
22:30:11 <John_Boyer> Erik: 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
22:32:21 <unl> s/Erik:/ebruchez:/
22:32:28 <John_Boyer> We were trying to avoid having form author ephemeral messages from displaying on startup in response to xforms-invalid messages
22:36:15 <John_Boyer> if the initial xforms-enabled simply indicated valid or not in context info, then that would work
22:36:44 <John_Boyer> Uli: I think there should be an xforms-invalid on initialization
22:37:31 <John_Boyer> Uli: The default on init is valid
22:40:40 <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
22:49:42 <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
22:51:34 <John_Boyer> Erik: controls update their mips and value, and then the events are dispatched to the control
22:56:24 <unl> s/Erik:/ebruchez:/
22:57:13 <unl> unl: first thing is: controls maintain their state, then we can figure out how events are supposed to work
22:57:51 <unl> John_Boyer: which state do they maintain in case of inherited non-relevance?
22:58:05 <unl> ebruchez/unl: the computed state 
23:00:34 <unl> John_Boyer: we need more event context information then 
23:00:49 <unl> ... wonder what that might be
23:02:36 <John_Boyer> scribe: John_Boyer
23:03:44 <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
23:08:40 <John_Boyer> Leigh: there is no law of excluded middle.  A non-relevant control could be neither valid or invalid
23:10:51 <John_Boyer> 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
23:11:09 <John_Boyer> Erik: We seem to need to listen for xforms-disabled to remove a control from an "invalid" list
23:12:23 <John_Boyer> 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.
23:13:29 <John_Boyer> Nick: The form author listens for enabled/disabled for validity trackging on create/destroy, and listen for xforms-valid/xforms-invalid for state change during the lifetime of the form.
23:14:54 <ebruchez> s/trackging/tracking
23:16:12 <John_Boyer> 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.
23:17:23 <John_Boyer> Nick: If you have a repeat with 5 rows, then the parent becomes non-relevant, the repeat stops updating
23:18:43 <John_Boyer> ... 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
23:43:08 <John_Boyer> Need to choose from among the following:
23:43:37 <John_Boyer> 1) On enable/disable, context info contains valid/invalid info
23:44:17 <John_Boyer> 2) On enable, xforms-invalid dispatched if needed, and on disable, xforms-valid gets dispatched even if control *was* bound to an invalid control
23:45:55 <John_Boyer> In case #1, the form author has to listen to enable/disable as part of tracking valid/invalid controls
23:46:49 <John_Boyer> In case #2, the form author only listens to valid/invalid events for trackging valid/invalid controls, but when a control becomes disabled, it receives a valid event even if it *was* bound to an invalid node
23:47:32 <ebruchez> s/trackging/tracking
23:48:22 <ebruchez> s/bound to an invalid control/bound to an invalid node
23:58:55 <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.