IRC log of forms on 2009-06-04

Timestamps are in UTC.

14:01:00 [RRSAgent]
RRSAgent has joined #forms
14:01:00 [RRSAgent]
logging to
14:01:01 [Steven]
zakim, room for 10 people for 3600 mins?
14:01:01 [Zakim]
Steven, are you serious? I'm going to give you 12 hours at most.
14:01:04 [Zakim]
ok, Steven; conference Team_(forms)14:01Z scheduled with code 26631 (CONF1) for 720 minutes until 0201Z
14:01:16 [Steven]
whoops :-)
14:01:42 [Steven]
zakim, dial steven-617
14:01:42 [Zakim]
I am sorry, Steven; I don't have the necessary resources to dial out right now
14:01:48 [Steven]
14:01:56 [Zakim]
Team_(forms)14:01Z has now started
14:02:02 [Zakim]
+ +1.302.566.aaaa
14:02:10 [kenneth]
zakim, i am +1.
14:02:10 [Zakim]
+kenneth; got it
14:02:13 [Steven]
zakim, dial steven-617
14:02:13 [Zakim]
I am sorry, Steven; I don't have the necessary resources to dial out right now
14:02:27 [Zakim]
14:02:32 [wiecha]
zakim, [IBM] is wiecha
14:02:32 [Zakim]
+wiecha; got it
14:02:57 [Zakim]
14:03:23 [nick1]
zakim, I am [IPcaller]
14:03:23 [Zakim]
ok, nick1, I now associate you with [IPcaller]
14:03:53 [Zakim]
14:04:41 [Zakim]
14:04:43 [klotz]
klotz has joined #forms
14:05:10 [John_Boyer]
Meeting: W3C Forms WG Virtual Face to Face 04 June 2009
14:05:29 [John_Boyer]
14:05:36 [John_Boyer]
Chair: John
14:05:40 [John_Boyer]
Regrets: Erik
14:06:05 [klotz]
zakim, code
14:06:05 [Zakim]
I don't understand 'code', klotz
14:06:17 [wiecha]
26631 (CONF1
14:06:26 [John_Boyer]
Scribe: Steven
14:06:30 [klotz]
thank you, wiecha, much better than zakim
14:06:51 [Zakim]
14:08:26 [John_Boyer]
Yugma session 315549410
14:10:33 [Steven]
Scribe: Steven
14:10:51 [Steven]
Chair: John
14:10:58 [Steven]
rrsagent, make minutes
14:10:58 [RRSAgent]
I have made the request to generate Steven
14:11:17 [Steven]
rrsagent, make log public
14:11:25 [Steven]
rrsagent, make minutes
14:11:25 [RRSAgent]
I have made the request to generate Steven
14:14:02 [John_Boyer]
14:14:11 [Steven]
Topic: XForms 1.1 PR
14:14:47 [Steven]
John: There are a few changes
14:15:03 [Steven]
... review period is to July 7
14:15:50 [Steven]
... but will have to be moved out
14:16:27 [Steven]
... and I'll be on vacation at the critical moment
14:16:35 [Steven]
... so it will get pushed back further
14:18:33 [John_Boyer]
14:18:44 [Steven]
... and I have update the bit about delete in section above
14:19:15 [Steven]
14:20:56 [Steven]
John: Furthermore, I have made it clear where attributes are optional to implement, and optional to author
14:21:01 [Steven]
... mind numbing work
14:21:36 [Steven]
... Further, in the introduction I have altered the discussion of MUST, SHOULD etc
14:25:01 [Steven]
Leigh: It doesn't explain words like author-optional properly
14:25:05 [Zakim]
14:25:23 [Steven]
zakim, who is here?
14:25:23 [Zakim]
On the phone I see kenneth, wiecha, John_Boyer, Steven, Leigh_Klotz
14:25:24 [Zakim]
On IRC I see klotz, RRSAgent, Zakim, John_Boyer, wiecha, kenneth, nick1, Steven, trackbot
14:25:33 [Steven]
John: How coculd I fix it?
14:25:41 [Steven]
14:26:54 [Steven]
Leigh: [discusses wording]
14:27:18 [Steven]
Leigh: We need a precise definition
14:32:05 [Steven]
[The discussion is between optional-to-implement features and optional-to-author]
14:33:27 [Steven]
Leigh: I still don't understand the current wording
14:36:43 [Steven]
Steven: Why is there a problem with optional, and not with required?
14:36:55 [Steven]
John: Because there is no ambiguity with required
14:37:08 [Steven]
... a required attribute is also required to be implemented
14:39:44 [nick]
nick has joined #forms
14:40:15 [nick]
zakim, code?
14:40:15 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), nick
14:40:40 [Zakim]
14:40:51 [nick]
zakim, I am ??P24
14:40:51 [Zakim]
+nick; got it
14:40:58 [Steven]
Charlie: Isn't there really a difference between the two meanings of required that is just being hidden?
14:44:05 [Steven]
Steven: Wouldn't it have been better to use another term for optional-to-implement. There seem to be many more examples of author-optional now, than bare optional
14:44:20 [Steven]
Charlie: But optional to implement should be the default meaning
14:44:45 [Steven]
John: Leigh, could you suggest some wording for this section?
14:44:55 [Steven]
Leigh: I'll try now...
14:46:09 [Steven]
rrsagent, make minutes
14:46:09 [RRSAgent]
I have made the request to generate Steven
14:46:43 [John_Boyer]
author-optional is like schema part 1's use=optional
14:47:03 [John_Boyer]
In schema, you can then, separately, say default="something" or you can have no default
14:50:11 [klotz]
The term author-optional, when applied to an element, attribute,
14:50:11 [klotz]
or function parameter, indicates to form authors that they may
14:50:11 [klotz]
omit the specified item, and obtain the specified default
14:50:11 [klotz]
behavior. The term author-optional is orthogonal to the
14:50:11 [klotz]
required, recommended, or optional conformance status of the
14:50:12 [klotz]
feature containing the specified item.
14:53:48 [klotz]
The term author-optional, when applied to an element, attribute, or function parameter, indicates to form authors that they may omit the specified item, and obtain the specified default behavior. The term author-optional is orthogonal to the conformance status (required, recommended, or optional) of the item.
14:55:24 [Steven]
John: Works for me
14:57:13 [Steven]
[Tweaking happens]
14:58:42 [John_Boyer]
The term 28<21term28>author-optional28</21term28>, when applied to a content item such as an element, attribute, or function parameter, indicates to form authors that they may omit the content item and obtain the default behavior. The term author-optional is orthogonal to the conformance status (required, recommended, or optional) of the content item.
14:59:50 [Zakim]
14:59:55 [Steven]
zakim, who is here?
14:59:55 [Zakim]
On the phone I see wiecha, John_Boyer, Steven, Leigh_Klotz, nick
14:59:56 [Zakim]
On IRC I see nick, klotz, RRSAgent, Zakim, John_Boyer, wiecha, Steven, trackbot
15:01:37 [Steven]
John: I have the editor's drafts
15:02:04 [Steven]
... if we are going to make a resolution, do I need a dated version?
15:02:39 [Steven]
Steven: Up to you; you could also avoid making changes
15:02:57 [Steven]
... until it gets published
15:03:49 [Steven]
... which will create a dated version
15:04:09 [Steven]
John: We have CVS, so we can always post-hoc create a dated version if needed
15:04:30 [Steven]
John: I'll check in a dated version
15:05:08 [John_Boyer]
I propose that we request advancement of XForms 1.1 to PR based on the document here:
15:05:11 [Steven]
15:06:03 [Steven]
15:06:17 [John_Boyer]
I propose that we request advancement of XForms 1.1 to PR based on the document here:
15:06:20 [Steven]
15:06:33 [nick]
15:06:36 [John_Boyer]
15:06:45 [wiecha]
15:06:53 [klotz]
15:07:07 [Steven]
RESOLUTION: request advancement of XForms 1.1 to PR based on the document here:
15:07:27 [Steven]
ACTION: Steven to request PR of XForms 1.1
15:07:27 [trackbot]
Created ACTION-543 - Request PR of XForms 1.1 [on Steven Pemberton - due 2009-06-11].
15:10:45 [nick]
not sure
15:10:54 [Steven]
[Group reviews the test results]
15:11:18 [Steven]
John: There are clear examples of FF ubiquity and IE ubiquity are different code bases
15:11:30 [Steven]
15:12:35 [Steven]
... where tests work in one, and not in the other
15:13:56 [Steven]
Steven: Why is EMC blank for appx B?
15:14:21 [Steven]
Nick: They didn't submit results for those tests
15:14:27 [Steven]
[take 5]
15:25:23 [Steven]
rrsagent, make minutes
15:25:23 [RRSAgent]
I have made the request to generate Steven
15:30:20 [Steven]
Topic: Future work
15:30:47 [Steven]
Charlie: What are the goals of current members?
15:31:05 [Steven]
Steven: To do it even better, now we have experience
15:31:51 [Zakim]
15:32:13 [Steven]
... where 'it' = the generalisation of concepts, not just 'forms'
15:32:59 [Steven]
Nick: I have a meeting planned with my company to try and work out what future sork means for us
15:33:08 [Steven]
15:33:30 [Steven]
... we need short-term deliverables
15:33:48 [Steven]
... components are important
15:35:01 [Steven]
John: The maintenance work is useful
15:35:33 [Steven]
... some features for better integration with documents
15:35:42 [Steven]
... point feature types of things
15:36:02 [Steven]
... for collaborative applications, with ODF documents for instance
15:36:16 [Steven]
... for ODF to be components in larger applications
15:37:17 [Steven]
... multiple-page web apps
15:37:45 [kenneth]
kenneth has joined #forms
15:37:46 [Steven]
... better integration with plain html
15:37:52 [kenneth]
zakim, code please
15:37:52 [Zakim]
I don't understand 'code', kenneth
15:37:57 [kenneth]
zakim, code please?
15:37:57 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), kenneth
15:38:22 [Zakim]
15:38:36 [Steven]
Charlie: Programming in the large
15:39:11 [Steven]
... hybrid client-server processing
15:40:10 [Steven]
Steven: Don't we have that already? Isn't the current model sufficiently abstract?
15:41:51 [Steven]
Charlie: Not sure
15:43:14 [Steven]
... I think we miss the APIs for javascript handlers
15:45:55 [Steven]
Steven: Isn't XBL a better approach for that?
15:46:32 [Steven]
Charlie: But this is still too bottom-up
15:46:54 [Steven]
... we need requirements analysis
15:48:45 [Steven]
Steven: XML is just a serialization of data
15:49:16 [Steven]
... and we look at data through XML glasses, but there is nothing essentially XML
15:49:55 [Steven]
... importing JSON data, you can still deal with it with XForms, but you end up using XPath to access it
15:51:04 [Steven]
Charlie: It is a good area to explore
15:51:30 [Steven]
John: Xpath acts on the data model, not on XML itself
15:52:13 [Steven]
15:54:18 [Steven]
Charlie: But it is not enough to go in and say that to Ajax people
15:56:37 [nick]
I'm not completely sure XML is a problem for us, Google Wave is completely backed by XML too, and I don't think it bothers anybody
15:56:55 [Steven]
Steven: Agree
15:57:25 [Steven]
Steven: The importnant thing is your expression language can do everything you need it for
15:57:40 [Steven]
... which is why CSS selectors are no good for us, and XPath is
15:57:52 [Steven]
... since there are things you can't do in CSS
15:58:03 [wiecha]
as far as i can see, XML in Wave is infrastructure -- carrying the protocol -- and not part of the UI
15:58:05 [Steven]
15:58:08 [John_Boyer]
At instance level, I care about the operations only. Can I parse, can I serialize, can I mutate.
15:58:11 [wiecha]
this is always where XML drops out
15:58:43 [Steven]
15:58:48 [Steven]
rrsagent, make minutes
15:58:48 [RRSAgent]
I have made the request to generate Steven
15:59:00 [John_Boyer]
for expression language, can I eval and can I get dependencies
15:59:04 [Zakim]
15:59:06 [John_Boyer]
rrsagent, make minutes
15:59:06 [RRSAgent]
I have made the request to generate John_Boyer
15:59:35 [Zakim]
16:00:55 [Zakim]
16:00:57 [Zakim]
16:00:57 [Zakim]
16:00:58 [Zakim]
Team_(forms)14:01Z has ended
16:00:59 [Zakim]
Attendees were +1.302.566.aaaa, kenneth, wiecha, [IPcaller], John_Boyer, Steven, Leigh_Klotz, nick
16:01:08 [John_Boyer]
rrsagent, make minutes
16:01:08 [RRSAgent]
I have made the request to generate John_Boyer
16:34:42 [klotz]
klotz has joined #forms
16:41:35 [nick]
nick has joined #forms
16:50:50 [Zakim]
Team_(forms)14:01Z has now started
16:50:57 [Zakim]
16:51:23 [Zakim]
16:51:24 [Zakim]
Team_(forms)14:01Z has ended
16:51:24 [Zakim]
Attendees were Leigh_Klotz
16:58:58 [Zakim]
Team_(forms)14:01Z has now started
16:59:05 [Zakim]
16:59:15 [wiecha]
zakim, [IBM] is wiecha
16:59:15 [Zakim]
+wiecha; got it
16:59:46 [John_Boyer]
zakim, code?
16:59:53 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), John_Boyer
17:00:08 [Zakim]
17:01:31 [Steven]
zakim, dial steven-617
17:01:31 [Zakim]
ok, Steven; the call is being made
17:01:32 [Zakim]
17:01:49 [Zakim]
17:02:43 [John_Boyer]
Scribe: Leigh
17:02:47 [John_Boyer]
scribenick: klotz
17:02:54 [John_Boyer]
zakim, who is here?
17:02:54 [Zakim]
On the phone I see wiecha, John_Boyer, Steven, Leigh_Klotz
17:02:55 [Zakim]
On IRC I see nick, klotz, kenneth, RRSAgent, Zakim, John_Boyer, wiecha, Steven, trackbot
17:03:33 [nick]
zakim, code?
17:03:33 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), nick
17:04:24 [Zakim]
17:04:40 [nick]
zakim, I am ??P7
17:04:40 [Zakim]
+nick; got it
17:05:27 [klotz]
John: Why an abstract model for XForms
17:05:42 [John_Boyer]
it's instructive to consider the answer to that
17:05:57 [klotz]
Charlie: What we have is broader than forms and broader than XML; maybe a representation independent of XML.
17:06:07 [klotz]
John: Bearing with me...
17:06:25 [klotz]
John: It gets at what we don't want to be limited at, not what we get by removing limitations.
17:08:09 [klotz]
Charlie: For non-XML platforms such as YUI and HTML5 and other AJAX libraries, needing declarative codebehind and other expressive features. We have a set of use cases to fill that HTML5 isn't aimed at, and they're real problems for developers to day.
17:08:22 [klotz]
John: The word is "people"
17:08:33 [klotz]
17:08:38 [klotz]
s/to day/today/
17:09:06 [klotz]
John: We're having a technical discussion about abstraction to make the work more relevant by more people.
17:09:13 [klotz]
Charlie: It comes back to the ecosystem.
17:09:49 [Zakim]
17:10:06 [klotz]
Charlie: We need to fill the gap with the problems people are having today that's leading them to invent MVC frameworks for AJAX libraries. There's a window of opportunity to fill the gap.
17:10:27 [klotz]
John: To appeal to the class of people who are trying to build things we need to give them actual technologies, not specifications.
17:10:37 [klotz]
Charlie: And in a 12-18 month timeframe.
17:11:32 [klotz]
Charlie: How is this different from what we said in Raleigh two years ago? We went off on spec modularization first.
17:11:39 [klotz]
John: The only thing the W3C WG produces is spcs.
17:11:44 [klotz]
17:12:21 [klotz]
John: We have a good idea of our architecture and did a good job on what we did, but we didn't finish. There are some good modules to split off.
17:12:55 [klotz]
John: The biggest complaint is that we aren't placing enough emphasis on the APIs.
17:13:14 [klotz]
John: Markup patterns would correspond to APIs; it's just work to write them down.
17:13:56 [klotz]
John: But we need an implementation that works out of the gate.
17:14:30 [klotz]
Charlie: I don't think we need to re-activate the spec modularization, but we do need a way to describe the components in a language-independent form. The schema modularization caused difficulties.
17:14:34 [nick]
I don't think that we have the resources to modularize the whole XForms spec
17:14:59 [klotz]
Charlie: An engineering effort of IDLs and JavaScript non-normative mapping would be useful.
17:15:04 [klotz]
John: A couple of modules at at time.
17:15:10 [klotz]
s/at at/at a/
17:15:28 [klotz]
John: Right, as Nick said, we don't have the resources to modularize the whole spec.
17:15:39 [klotz]
John: I don't know that anything less is going to happen in the fullness of time.
17:18:00 [klotz]
John: What would be M12N first?
17:18:09 [klotz]
Charlie: The model part first, whether XML or JSON.
17:18:27 [klotz]
Charlie: I think you can approach MVC incrementally.
17:18:39 [klotz]
John: Is there a particular theme, or is that too low level?
17:19:57 [John_Boyer]
Yugma 315 549 410
17:20:03 [John_Boyer]
without spaces
17:20:55 [klotz]
Steven: So who are the customers? HTML Forms web builder? MVC architecture abstraction benefits?
17:21:20 [klotz]
Steven: You don't get the same benefits by plugging bits of XForms into another architecture.
17:22:29 [klotz]
Steven: ...
17:22:50 [klotz]
Charlie: Those are the people using Dojo and other AJAX libraries today, who are struggling with MVC.
17:24:09 [klotz]
Charlie: These are groups who are unserved by the W3C focus on HTML5. There is a real need for us to help with.
17:24:33 [klotz]
John: Programming in Large theme?
17:24:44 [klotz]
Charlie: Generalizing Theme.
17:25:19 [klotz]
John: So the folks using Dojo have data ... problems.
17:25:30 [klotz]
Charlie: How do we deliver a data-centric architecture in XML and non-XML
17:26:06 [klotz]
Charlie: Title for theme.
17:26:28 [klotz]
Charlie: It's a spin on Ubqiuity theme.
17:27:04 [klotz]
John: data-intensive client programming rich open web
17:27:53 [John_Boyer]
s/rich/mvc ubiquitously usable
17:27:56 [klotz]
17:28:23 [Steven]
17:28:49 [klotz]
"OpenMVC: a non-proprietry component-based framework for web applications"
17:29:48 [nick]
In my opinion you could achieve this by keeping XML in the back-end and creating a Javascript/AJAX view on top of our XML model, in other words map JSON data to XML and a Javascript API that directly changes the Javascript objects which are backed by the XML data model.
17:30:04 [klotz]
John: Generally people think of the browser as the view, and control is in the middle tier, operating over a data model, passive, not active like ours.
17:30:20 [klotz]
Charlie: That's the traditional JSP view.
17:30:32 [klotz]
John: People don't understand how we're getting MVC to happen on the client.
17:30:38 [klotz]
Charlie: You can talk about recursive MVC.
17:31:36 [klotz]
John: There's client level interaction and server side business process. Right now all the page dynamism is picky, low-level imperative construct.
17:31:55 [klotz]
Charlie: There have been a few client-side examples now: Sliverlight, Flex, Data Binding in Dojo.
17:32:14 [klotz]
Charlie: We no longer have to argue against JSP.
17:32:28 [John_Boyer]
17:32:52 [klotz]
That's Sliverlight (TM)
17:33:11 [klotz]
John: What's different about Silverlight, Flex, Data binding in Dojo
17:33:22 [klotz]
Charlie: They're infrastructure. There's constraint propagation across the docuemnt.
17:34:37 [klotz]
John: Why would someone use Flex over open XForms? Or Silverlight?
17:36:56 [klotz]
Kenneth: ...
17:37:20 [klotz]
Charlie: Rapid integration and prototyping lets them decompose, work in parallel, and evolve into introduction.
17:38:03 [klotz]
Kenneth: One of the main things missing is the ability to create an attractive UI ... more control of the UI.
17:38:32 [klotz]
John: It has to look good. I agree.
17:39:32 [John_Boyer]
I agree with separation of concerns, but also that one of the concerns needs to be quality of UI, and that's one of the big reasons why the proprietary formats are attractive
17:39:39 [klotz]
Charlie: These apps aren't that different from XForms+CSS.
17:39:57 [klotz]
Charlie: I agree that we need good graphics too; it's within reach.
17:40:13 [nick]
But in my opinion the tooling to create nice looking UIs is better for Flex then for HTML
17:41:29 [nick]
... XHTML + CSS is more complex then Flex for graphical people
17:41:31 [klotz]
Charlie: And design tools.
17:41:50 [klotz]
John: We wind up creating design tools and sub-languages.
17:41:59 [klotz]
John: It's easier to recognize declarative patterns even in noise.
17:42:44 [klotz]
John: If the patterns are in script, they get larger, as do the customizations.
17:42:54 [klotz]
John: So it becomes impossible for the design tool.
17:43:25 [klotz]
Leigh: Isn't that an argument for something like XBL?
17:44:18 [nick]
+1 for this
17:44:39 [klotz]
Leigh: So use XBL or something like it for the UI ultimate control and customizations but bind the markup to it for declarative operations.
17:45:01 [klotz]
John: In Ubiquity we use a rules-based decorator approach that I think is analogous to XBL.
17:45:18 [klotz]
Charlie: The lack of XBL is what leads us to re-write it in JavaScript.
17:45:33 [klotz]
Charlie: XBL could do all the stuff.
17:45:49 [klotz]
John: To be concrete, XBL is really the way to attaching Dojo on to XForms.
17:46:03 [klotz]
Leigh: You mean the UI library of Dojo?
17:46:06 [wiecha]
s/re-write it/provide alternative decorations for different platforms
17:46:16 [klotz]
John: The presentation library of Dojo.
17:46:58 [klotz]
John: The more we say people can use what they want with our stuff, they more willing they are to use our stuff.
17:47:57 [klotz]
Charlie: I don't know if we need to pick an extension mechanism. there was a lot of pressure for extensibility in the browser for HTML5. It wasn't clear XBL was it.
17:48:09 [klotz]
Charlie: But whatever engine that is gives us a way to get into these different environments.
17:48:18 [klotz]
John: I hate to say it but we need ABL.
17:48:29 [klotz]
Charlie: I've seen a JavaScript implementation of XBL.
17:48:33 [klotz]
John: And XPath.
17:49:06 [klotz]
John: Having stuff around that works ...
17:49:31 [klotz]
John: Some of the shock comes from "nice spec but a lot of work to do before I use it to make my life easier."
17:50:08 [klotz]
Charlie: I don't care much about DOM consistency. Sam Ruby's discussion on his blog was about DOM consistency in HTML and XML parsers with prefixes, which we abstract over.
17:50:38 [wiecha]
17:51:04 [klotz]
Leigh: Charlie, I'm having trouble hearing you.
17:51:38 [klotz]
John: Now for HTML Web Builders.
17:51:56 [klotz]
Charlie: Do we dedicate resources in this WG for HTML webapp builders?
17:52:03 [John_Boyer]
that's the question, is this a group we want to target?
17:52:18 [klotz]
s/Web Builders/Web App Builders/
17:52:38 [klotz]
John: I actually deliberately used the term "Web Builders" as Steven did.
17:52:55 [klotz]
Charlie: I think there are two questions: the HTML world, and then the Forms world vs App world.
17:54:00 [klotz]
John: HTML parser limitations; DOM overload limitations; validity.
17:56:00 [klotz]
John: The HTML5 people point out the DOM issues; then there's a possible other group of validity-oriented people, for whom the AJAX presentation library work we need to do to get it in the browser
17:56:28 [klotz]
Charlie: That's an interesting observation: narrow HTML compatibility on one hand and extensibility mechanisms on the other.
17:57:49 [klotz]
John: HTML5 needs browser support already from other vendors; I don't see how they avoid the same issues as the AJAX presentational people; in order to reach the whole web with a new language, at least in the short term.
17:58:26 [klotz]
Charlie: So the question in the table?
17:58:43 [klotz]
John: Are we targeting HTML webapp builders?
17:59:25 [klotz]
John: Web apps deployable in the majority of today's browsers?
17:59:41 [klotz]
Charlie: And binding mechanisms or guidelines to actual implementations of APIs.
17:59:56 [klotz]
John: This is a good question because it's really a dividing point in the WG discussions.
18:00:16 [klotz]
John: Targeting the majority of today's web browsers is figuring out how to apply what we have.
18:00:39 [klotz]
John: That's a different conversation from re-architecting what we have to create a next generation.
18:00:42 [klotz]
Charlie: Yes.
18:01:45 [klotz]
Leigh: so is "targetting today's browsers" with "implementations or recommendations for bindings to APIs" what I often call the Ubiquity Benevolence Society?
18:02:07 [klotz]
John: I think so in that it ends with a reference implementation.
18:03:09 [klotz]
Charlie: The UBS does the implementation in some syntax, but not the abstraction or standardization.
18:03:22 [klotz]
John: Not at this point, but Mark asked when we can start doing that kind of thinking.
18:04:31 [klotz]
Leigh: I think the order needs to go the other way.
18:07:04 [klotz]
Leigh: I think you can implement the JavaScript and come back and say what you've done and we can turn it into a spec.
18:07:20 [klotz]
Charlie: I think we need to iterate it. It's not a done deal once it's implemented.
18:07:28 [klotz]
John: It needs to start.
18:07:40 [klotz]
Leigh: It doesn't need to start with the spec, but the implementation.
18:08:11 [klotz]
John: We already have a spec and the spec work has been done. To broaden the appeal we need to model it.
18:09:20 [klotz]
Leigh: I'll say what I said a year ago: come back with the data island library and we can write the spec.
18:09:39 [klotz]
John: I think that the group is the Ubiquity Benevolence Society. I'm not sure the work needs to be implemented.
18:10:14 [John_Boyer]
yes the work does need to be implemented
18:10:29 [John_Boyer]
I'm not sure it can really be implemented by others
18:10:57 [John_Boyer]
I think the implementation is just a tool for figuring out what the APIs really need to be
18:11:47 [John_Boyer]
If the specification really needs to be more abstract where we have a model composed of objects and methods
18:29:17 [wiecha]
rrsagent, make minutes
18:29:17 [RRSAgent]
I have made the request to generate wiecha
18:32:42 [klotz]
Leigh: I'd like to see UBS produce an initial implementation experiment for this WG to turn into a REC-track document.
18:32:48 [klotz]
John: What do others want to talk about?
18:33:09 [klotz]
Steven: I think there's a great future in XForms and I think we should carry on making it better. The better it is, the more likely it will be adopted.
18:33:23 [klotz]
Steven: The easier we make it, the less claim that it's difficult.
18:34:07 [klotz]
Steven: In good faith, we used other people's solutions which ended up creating difficulties; we did that in good faith to remain good XML citizens. If we want to focus on people, which many W3C architectures including HTML do not do, that's how we should work.
18:34:16 [klotz]
John: So take a look at XForms and the requirements.
18:34:56 [klotz]
Steven: If we want to answer some of Leigh's questions, the bootstrapping off the backplane work is a good approach, because we can get others interested as well. There are parts of XForms which are useful to others, as we've seen SMIL use our instance.
18:35:17 [klotz]
Steven: We know perfectly well that the model and UI are separable, with a binding between the two; those are two different parts of a backplane.
18:35:35 [klotz]
Steven: So I think there are areas where we can work on that. Of course, it's a question of finding people interested to be in it.
18:35:43 [klotz]
Steven: That involves selling ideas to member organizations.
18:36:11 [klotz]
Steven: Top-down taht's what I want to d.
18:36:12 [klotz]
klotz has left #forms
18:36:30 [klotz]
klotz has joined #forms
18:37:01 [klotz]
18:37:06 [klotz]
John: Can we drill down?
18:37:24 [nick]
things I'm personally interested are not so 'big' but are 'pluggable' components, dialogs, XPath 2.0, JSON 'instances', (and other small improvements) (but this is bottom up)
18:37:52 [John_Boyer]
bio break
18:37:53 [Zakim]
18:40:07 [nick]
and the patterns for repeat and other 'controls' that are available in all 'AJAX' and other frameworks, specified using our component framework
18:44:34 [Steven]
zakim, dial steven-617
18:44:34 [Zakim]
ok, Steven; the call is being made
18:44:36 [Zakim]
18:46:27 [wiecha]
Scribe: wiecha
18:46:51 [wiecha]
John: Steven, can you elaborate your comments about top-down requirements?
18:47:15 [wiecha]
Steven: we designed XForms by looking at how forms were used on the web and formulating requirements for forms and building something around that
18:47:24 [wiecha]
... out of that process the MVC architecture emerged
18:47:34 [wiecha]
... it's obvious that it was forms that was driving it in the beginning
18:47:54 [wiecha]
... the fact that the URL was a static string for submission, was how forms were previously
18:48:14 [wiecha]
... now, if I were to start from user requirements it would be even more general than it was
18:48:36 [wiecha]
... a lot would look the same but it would be more general and more usable
18:48:58 [wiecha]
perhaps not enormous difference, but more usable in different circumstances and for different ends
18:49:34 [wiecha]
John: what's relative value of creating more extension points vs. rich behavior features (patterns)
18:50:02 [wiecha]
Steven: has to be general, turing-complete, want to be able to attach anything to it
18:50:26 [wiecha]
... input control is about as general as it could this point we're collecting info and binding somewhere...doesn't say what's being collected
18:50:38 [wiecha]
... so that's a hook for saying how you're going to collect it
18:51:00 [wiecha]
... at present, for example, we use datatype but could also use xbl or something similar to build any sort of control that matches that input type
18:51:16 [wiecha]
John: on that point, i've always looked at it as a mistake that we have any controls other than input or output
18:51:21 [wiecha]
Steven: agree, hit it on the head
18:51:37 [wiecha]
... part of that is good design needs compromise otherwise fools fail to find it wise
18:51:59 [wiecha]
... include specific controls just to match expectations
18:52:25 [wiecha]
... but it's not required...probably bad design decision to have constant set of input values, e.g. for a select1 or of labels
18:52:41 [wiecha]
... in general not constant/fixed set. not even a known set when written
18:52:47 [wiecha]
... and for localization etc
18:52:59 [wiecha]
... input and output ideally all you want
18:53:35 [wiecha]
... but then need a methodology to say further things about that input or output
18:53:46 [wiecha]
... which depends on device and other aspects
18:54:13 [wiecha]
... e.g. maps
18:55:05 [wiecha]
John: how do we get to cluster of topics we have pending?
18:55:38 [wiecha]
... how offer a feature like allowing authors to add their own xpath functions? cross-platform way to do this
18:55:49 [wiecha]
... maybe built from smaller xforms actions
18:56:13 [wiecha]
... or different features around submission/model patterns for multiple page apps
18:56:33 [wiecha]
... captures what people are trying to do with today's xforms that make it simpler
18:56:43 [wiecha]
Steven: yes, packaging that we can't do in current xforms
18:57:08 [wiecha]
... creating abstractions for the larger design
18:57:38 [wiecha]
could use XBL again here to package XForms declarative markup in higher level patterns
18:58:18 [wiecha]
Steven: sodoku example writing out binds 1 by 1...very hard without repeat in the model
18:59:26 [wiecha]
John: looking at multiple pages working together to achieve the total app is another hard pattern today
19:00:02 [wiecha]
this is an example of the hybrid client/server model i think
19:01:54 [wiecha]
Steven: another point is submission has to go somewhere else out of the form, want sometimes to "submit" somewhere else in the same form, e.g. to another instance
19:02:25 [wiecha]
John: have something similar now with insert
19:02:55 [wiecha]
... submission element is something which is invoked by something else, i.e. send
19:03:26 [wiecha]
Steven: today, submission seems geared to large-scale constraint to manage relationship outside the form
19:03:42 [wiecha]
John: starts to relate to structural calculate
19:04:48 [wiecha]
Steven: relevance is like this...when condition relevant, drive an action like submission
19:05:03 [wiecha]
John: that's true of all mutations
19:05:39 [wiecha]
Steven: general picture should be to see things as constraints...update as a result of other changes. submission just a tool in this process
19:06:08 [wiecha]
John: why can't we today use submission to apply within-forms?
19:06:28 [wiecha]
... URI pointing inside current document
19:06:37 [wiecha]
Steven: could be defined that way but sure no impl does that
19:07:02 [wiecha]
Leigh: submit to submission vs. to instance
19:07:55 [wiecha]
John: is there more interest in looking at current xforms and building up more extension points?
19:08:22 [wiecha]
vs. analyzing and features in what we've seen doing in xforms?
19:08:31 [wiecha]
Steven: pls explain
19:09:11 [wiecha]
John: we have some extensibility already in that we allow authors to hook events in and do custom actions, but we have no way for authors to define xpath functions, MIPs, or actions
19:09:17 [wiecha]
Steven: yes, agree
19:09:56 [wiecha]
John: for MIPs, for example, to be able to define a new property, give name, give value. specify and query over that new value
19:10:10 [wiecha]
Steven: or influence presentation based on that
19:10:16 [wiecha]
... e.g. negative values
19:10:44 [wiecha]
John: metadata for UI controls, hint help alert, these are really MIPs
19:11:39 [wiecha]
... more about data than UI control
19:11:55 [wiecha]
Steven: hint/help about model?
19:12:24 [wiecha]
John: in the loan form the alert would be reflecting loan business constraints
19:12:50 [wiecha]
... hint on that data is still what the data is...more info on that data...could be provided to any form control
19:13:06 [wiecha]
Steven: hint/help more likely model based than UI based
19:13:30 [wiecha]
John: just examples of things we currently have that could be better handled as MIPs
19:13:49 [wiecha]
... would help integration with other technologies. using MIPs easier than markup
19:13:55 [wiecha]
... e.g. data node is digitally signed
19:14:29 [wiecha]
... we don't provide extensibility for applications to define their own metadata here
19:14:47 [wiecha]
Steven: yes, these are all examples of coming from static form design and discovering more dynamic issues involved
19:14:52 [wiecha]
... not just about forms
19:15:10 [nick]
I also agree that extensibility could/should also be a theme for a future version
19:15:17 [wiecha]
John: seem to be three themes: author extensibility,
19:15:24 [wiecha]
... pattern characterization,
19:15:30 [wiecha]
... feature broadening
19:15:47 [nick]
19:15:50 [wiecha]
... submission extensions (binary resources)
19:17:30 [wiecha]
John: ...discusses upload example of generalized functions
19:18:36 [wiecha]
... we assume delivery of final result is a single step...upload "conversation" is multi-step w/server
19:19:02 [wiecha]
... not sure if this is "feature broadening" or "pattern characterization"
19:19:13 [wiecha]
...feature broadening is the way we achieve the result
19:20:51 [Steven]
19:21:12 [wiecha]
Leigh: REST design of expressing stateful conversation would be to have support for URI-addressed temporary resources
19:21:23 [wiecha]
... with declarative support for making that easy to express
19:21:39 [wiecha]
... e.g. server-side persistence based on headers
19:21:44 [wiecha]
John: that's the how vs. what
19:22:07 [wiecha]
... we have some experiments here
19:22:21 [wiecha]
Leigh: need to explicitly design for this for the web
19:22:27 [nick]
Another feature that we currently have in our implementation, and is not allowed by the spec, is a textarea that bounds to a subtree that contains xlsfo (mediatype). Allowing to bound to a subtree allows the author to put constraints on allowed fonts, elements, sizes,... of the entered rich text
19:22:31 [wiecha]
... vs RMI it's all procedure calls
19:23:02 [wiecha]
Leigh: so don't agree that state rep is means to's guiding principle. but need declarative way that's easy to use
19:23:28 [wiecha]
John: three levels: what to build (themes?), how to design them, and in the middle the guiding principles
19:24:00 [wiecha]
John: Nick, agree...if we have a text area (input!) ...
19:24:10 [wiecha]
Nick: yes, not only binding to first text node but more generally to subtree
19:24:18 [wiecha]
John: +1
19:25:23 [wiecha]
... these more composite bindings are like submit w/instance replace
19:25:52 [wiecha]
Leigh: that's what was done for select
19:26:14 [wiecha]
John: also submission instance replacement, defined in terms of insert/delete actions
19:26:25 [wiecha]
and replace text in terms of setvalue
19:26:44 [wiecha]
... yet another extension could be that form controls could do more than setvalue if we can extend definition of "ref"
19:27:13 [wiecha]
silverlight has transformation layer between model and view
19:30:33 [wiecha]
Leigh: should we try to define abstract markup that then operates over silverlight and flex?
19:31:33 [wiecha]
... e.g. as our runtime platform, vs the raw browsers
19:32:00 [wiecha]
John: thought that's where we were going, but hadn't talked about integration of improved features into them as host language
19:32:10 [wiecha]
Leigh: think ubiquity for silverlight and flex
19:32:51 [wiecha]
... is there a way to start standards effort around consistent MVC architecture?
19:34:01 [wiecha]
John: topic of targeting existing HTML authors is a different conversation from targeting flex/silverlight class apps
19:34:14 [wiecha]
Leigh: yes, those who have already decided to target these more complex platforms
19:34:20 [wiecha]
... and look for standardization
19:34:33 [wiecha]
John: already a lot of committed proprietary work
19:41:07 [wiecha]
John: we'd need some significant seed members
19:41:17 [wiecha]
Leigh: don't need browser vendor "permission"
19:41:24 [wiecha]
... also Laszlo is in this space
19:42:59 [wiecha]
John: for a couple of days now we've been discussing proposing a substantially new group/mission
19:43:52 [wiecha]
Steven: still exploring this vs. recharting forms group
19:44:09 [wiecha]
19:48:56 [wiecha]
John: focus on improvements of xforms in documents, and collaborative workflow patterns
19:49:12 [wiecha]
... seem to be areas that are forward looking
19:49:16 [wiecha]
... and then extension points
19:51:47 [wiecha]
... conversations aren't about "forms" it's about business processes and total application story
20:00:25 [wiecha]
Nick: sometimes we see forms in the context of processes sometimes not
20:02:05 [Zakim]
20:02:07 [Zakim]
20:02:07 [Zakim]
20:02:08 [Zakim]
20:02:11 [Zakim]
20:02:13 [Zakim]
20:02:13 [Zakim]
Team_(forms)14:01Z has ended
20:02:14 [Zakim]
Attendees were wiecha, John_Boyer, Steven, Leigh_Klotz, nick, kenneth
20:02:30 [John_Boyer]
rrsagent, make minutes
20:02:30 [RRSAgent]
I have made the request to generate John_Boyer
20:02:57 [John_Boyer]
rrsagent, bye
20:02:57 [RRSAgent]
I see 1 open action item saved in :
20:02:57 [RRSAgent]
ACTION: Steven to request PR of XForms 1.1 [1]
20:02:57 [RRSAgent]
recorded in