W3C Forms WG Virtual Face to Face 04 June 2009 -- 04 Jun 2009

<Steven> whoops :-)

<Steven> woh!

<wiecha> 26631 (CONF1

<John_Boyer> Scribe: Steven

<klotz> thank you, wiecha, much better than zakim

<John_Boyer> Yugma session 315549410

<scribe> Scribe: Steven

<scribe> Chair: John

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html

XForms 1.1 PR

John: There are a few changes
... review period is to July 7
... but will have to be moved out
... and I'll be on vacation at the critical moment
... so it will get pushed back further

<John_Boyer> http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#action-delete

John: and I have updated the bit about delete in section above
... Furthermore, I have made it clear where attributes are optional to implement, and optional to author
... mind numbing work
... Further, in the introduction I have altered the discussion of MUST, SHOULD etc

Leigh: It doesn't explain words like author-optional properly

John: How could I fix it?

Leigh: [discusses wording]
... We need a precise definition

[The discussion is between optional-to-implement features and optional-to-author]

Leigh: I still don't understand the current wording

Steven: Why is there a problem with optional, and not with required?

John: Because there is no ambiguity with required
... a required attribute is also required to be implemented

Charlie: Isn't there really a difference between the two meanings of required that is just being hidden?

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

Charlie: But optional to implement should be the default meaning

John: Leigh, could you suggest some wording for this section?

Leigh: I'll try now...

<John_Boyer> author-optional is like schema part 1's use=optional

<John_Boyer> In schema, you can then, separately, say default="something" or you can have no default

<klotz> The term author-optional, when applied to an element, attribute,

<klotz> or function parameter, indicates to form authors that they may

<klotz> omit the specified item, and obtain the specified default

<klotz> behavior. The term author-optional is orthogonal to the

<klotz> required, recommended, or optional conformance status of the

<klotz> feature containing the specified item.

<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.

John: Works for me

[Tweaking happens]

<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.

John: I have the editor's drafts
... if we are going to make a resolution, do I need a dated version?

Steven: Up to you; you could also avoid making changes
... until it gets published
... which will create a dated version

John: We have CVS, so we can always post-hoc create a dated version if needed
... I'll check in a dated version

<John_Boyer> I propose that we request advancement of XForms 1.1 to PR based on the document here: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-diff-20090604.html

-1

<John_Boyer> I propose that we request advancement of XForms 1.1 to PR based on the document here: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all-20090604.html

<nick> +1

<John_Boyer> +1

<wiecha> +1

<klotz> +1

RESOLUTION: request advancement of XForms 1.1 to PR based on the document here: http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all-20090604.html

<scribe> ACTION: Steven to request PR of XForms 1.1 [recorded in http://www.w3.org/2009/06/04-forms-minutes.html#action01]

<trackbot> Created ACTION-543 - Request PR of XForms 1.1 [on Steven Pemberton - due 2009-06-11].

<nick> not sure

[Group reviews the test results]

John: There are clear examples of FF ubiquity and IE ubiquity being different code bases
... where tests work in one, and not in the other

Steven: Why is EMC blank for appx B?

Nick: They didn't submit results for those tests

[take 5]

Future work

Charlie: What are the goals of current members?

Steven: To do it even better, now we have experience
... where 'it' = the generalisation of concepts, not just 'forms'

Nick: I have a meeting planned with my company to try and work out what future work means for us
... we need short-term deliverables
... components are important

John: The maintenance work is useful
... some features for better integration with documents
... point feature types of things
... for collaborative applications, with ODF documents for instance
... for ODF to be components in larger applications
... multiple-page web apps
... better integration with plain html

Charlie: Programming in the large
... hybrid client-server processing

Steven: Don't we have that already? Isn't the current model sufficiently abstract?

Charlie: Not sure
... I think we miss the APIs for javascript handlers

Steven: Isn't XBL a better approach for that?

Charlie: But this is still too bottom-up
... we need requirements analysis

Steven: XML is just a serialization of data
... and we look at data through XML glasses, but there is nothing essentially XML
... importing JSON data, you can still deal with it with XForms, but you end up using XPath to access it

Charlie: It is a good area to explore

John: Xpath acts on the data model, not on XML itself

a/Xp/XP/

Charlie: But it is not enough to go in and say that to Ajax people

<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

Steven: Agree
... The important thing is your expression language can do everything you need it for
... which is why CSS selectors are no good for us, and XPath is
... since there are things you can't do in CSS

<wiecha> as far as i can see, XML in Wave is infrastructure -- carrying the protocol -- and not part of the UI

<John_Boyer> At instance level, I care about the operations only. Can I parse, can I serialize, can I mutate.

<wiecha> this is always where XML drops out

[BREAK]

<John_Boyer> for expression language, can I eval and can I get dependencies

<John_Boyer> Scribe: Leigh

<John_Boyer> scribenick: klotz

John: Why an abstract model for XForms

<John_Boyer> it's instructive to consider the answer to that

Charlie: What we have is broader than forms and broader than XML; maybe a representation independent of XML.

John: Bearing with me...
... It gets at what we don't want to be limited at, not what we get by removing limitations.

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 people today.

John: The word is "people"
... We're having a technical discussion about abstraction to make the work more relevant by more people.

Charlie: It comes back to the ecosystem.
... 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.

John: To appeal to the class of people who are trying to build things we need to give them actual technologies, not specifications.

Charlie: And in a 12-18 month timeframe.
... How is this different from what we said in Raleigh two years ago? We went off on spec modularization first.

John: The only thing the W3C WG produces is specs.
... 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.
... The biggest complaint is that we aren't placing enough emphasis on the APIs.
... Markup patterns would correspond to APIs; it's just work to write them down.
... But we need an implementation that works out of the gate.

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.

<nick> I don't think that we have the resources to modularize the whole XForms spec

Charlie: An engineering effort of IDLs and JavaScript non-normative mapping would be useful.

John: A couple of modules at a time.
... Right, as Nick said, we don't have the resources to modularize the whole spec.
... I don't know that anything less is going to happen in the fullness of time.
... What would be M12N first?

Charlie: The model part first, whether XML or JSON.
... I think you can approach MVC incrementally.

John: Is there a particular theme, or is that too low level?

<John_Boyer> Yugma 315 549 410

<John_Boyer> without spaces

Steven: So who are the customers? HTML Forms web builder? MVC architecture abstraction benefits?
... You don't get the same benefits by plugging bits of XForms into another architecture.
... ...

Charlie: Those are the people using Dojo and other AJAX libraries today, who are struggling with MVC.
... These are groups who are unserved by the W3C focus on HTML5. There is a real need for us to help with.

John: Programming in Large theme?

Charlie: Generalizing Theme.

John: So the folks using Dojo have data ... problems.

Charlie: How do we deliver a data-centric architecture in XML and non-XML
... Title for theme.
... It's a spin on Ubqiuity theme.

John: data-intensive client programming mvc ubiquitously usable open web

javax.forms

<Steven> OpenMVC

"OpenMVC: a non-proprietry component-based framework for web applications"

<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.

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.

Charlie: That's the traditional JSP view.

John: People don't understand how we're getting MVC to happen on the client.

Charlie: You can talk about recursive MVC.

John: There's client level interaction and server side business process. Right now all the page dynamism is picky, low-level imperative construct.

Charlie: There have been a few client-side examples now: Silverlight, Flex, Data Binding in Dojo.
... We no longer have to argue against JSP.

That's Sliverlight (TM)

John: What's different about Silverlight, Flex, Data binding in Dojo

Charlie: They're infrastructure. There's constraint propagation across the docuemnt.

John: Why would someone use Flex over open XForms? Or Silverlight?

Kenneth: ...

Charlie: Rapid integration and prototyping lets them decompose, work in parallel, and evolve into introduction.

Kenneth: One of the main things missing is the ability to create an attractive UI ... more control of the UI.

John: It has to look good. I agree.

<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

Charlie: These apps aren't that different from XForms+CSS.
... I agree that we need good graphics too; it's within reach.

<nick> But in my opinion the tooling to create nice looking UIs is better for Flex then for HTML

<nick> ... XHTML + CSS is more complex then Flex for graphical people

Charlie: And design tools.

John: We wind up creating design tools and sub-languages.
... It's easier to recognize declarative patterns even in noise.
... If the patterns are in script, they get larger, as do the customizations.
... So it becomes impossible for the design tool.

Leigh: Isn't that an argument for something like XBL?

<nick> +1 for this

Leigh: So use XBL or something like it for the UI ultimate control and customizations but bind the markup to it for declarative operations.

John: In Ubiquity we use a rules-based decorator approach that I think is analogous to XBL.

Charlie: The lack of XBL is what leads us to provide alternative decorations for different platforms in JavaScript.
... XBL could do all the stuff.

John: To be concrete, XBL is really the way to attaching Dojo on to XForms.

Leigh: You mean the UI library of Dojo?

John: The presentation library of Dojo.
... The more we say people can use what they want with our stuff, they more willing they are to use our stuff.

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.
... But whatever engine that is gives us a way to get into these different environments.

John: I hate to say it but we need ABL.

Charlie: I've seen a JavaScript implementation of XBL.

John: And XPath.
... Having stuff around that works ...
... Some of the shock comes from "nice spec but a lot of work to do before I use it to make my life easier."

Charlie: I don't know 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.

Leigh: Charlie, I'm having trouble hearing you.

John: Now for HTML Web App Builders.

Charlie: Do we dedicate resources in this WG for HTML webapp builders?

<John_Boyer> that's the question, is this a group we want to target?

John: I actually deliberately used the term "Web Builders" as Steven did.

Charlie: I think there are two questions: the HTML world, and then the Forms world vs App world.

John: HTML parser limitations; DOM overload limitations; validity.
... 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

Charlie: That's an interesting observation: narrow HTML compatibility on one hand and extensibility mechanisms on the other.

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.

Charlie: So the question in the table?

John: Are we targeting HTML webapp builders?
... Web apps deployable in the majority of today's browsers?

Charlie: And binding mechanisms or guidelines to actual implementations of APIs.

John: This is a good question because it's really a dividing point in the WG discussions.
... Targeting the majority of today's web browsers is figuring out how to apply what we have.
... That's a different conversation from re-architecting what we have to create a next generation.

Charlie: Yes.

Leigh: so is "targetting today's browsers" with "implementations or recommendations for bindings to APIs" what I often call the Ubiquity Benevolence Society?

John: I think so in that it ends with a reference implementation.

Charlie: The UBS does the implementation in some syntax, but not the abstraction or standardization.

John: Not at this point, but Mark asked when we can start doing that kind of thinking.

Leigh: I think the order needs to go the other way.
... I think you can implement the JavaScript and come back and say what you've done and we can turn it into a spec.

Charlie: I think we need to iterate it. It's not a done deal once it's implemented.

John: It needs to start.

Leigh: It doesn't need to start with the spec, but the implementation.

John: We already have a spec and the spec work has been done. To broaden the appeal we need to model it.

Leigh: I'll say what I said a year ago: come back with the data island library and we can write the spec.

John: I think that the group is the Ubiquity Benevolence Society. I'm not sure the work needs to be implemented.

<John_Boyer> yes the work does need to be implemented

<John_Boyer> I'm not sure it can really be implemented by others

<John_Boyer> I think the implementation is just a tool for figuring out what the APIs really need to be

<John_Boyer> If the specification really needs to be more abstract where we have a model composed of objects and methods

Leigh: I'd like to see UBS produce an initial implementation experiment for this WG to turn into a REC-track document.

John: What do others want to talk about?

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.
... The easier we make it, the less claim that it's difficult.
... 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.

John: So take a look at XForms and the requirements.

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.
... 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.
... 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.
... That involves selling ideas to member organizations.
... Top-down that's what I want to d.

John: Can we drill down?

<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)

<John_Boyer> bio break

<nick> and the patterns for repeat and other 'controls' that are available in all 'AJAX' and other frameworks, specified using our component framework

<wiecha> Scribe: wiecha

John: Steven, can you elaborate your comments about top-down requirements?

Steven: we designed XForms by looking at how forms were used on the web and formulating requirements for forms and building something around that
... out of that process the MVC architecture emerged
... it's obvious that it was forms that was driving it in the beginning
... the fact that the URL was a static string for submission, was how forms were previously
... now, if I were to start from user requirements it would be even more general than it was
... a lot would look the same but it would be more general and more usable

perhaps not enormous difference, but more usable in different circumstances and for different ends

John: what's relative value of creating more extension points vs. rich behavior features (patterns)

Steven: has to be general, turing-complete, want to be able to attach anything to it
... input control is about as general as it could get...at this point we're collecting info and binding somewhere...doesn't say what's being collected
... so that's a hook for saying how you're going to collect it
... 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

John: on that point, i've always looked at it as a mistake that we have any controls other than input or output

Steven: agree, hit it on the head
... part of that is good design needs compromise otherwise fools fail to find it wise
... include specific controls just to match expectations
... but it's not required...probably bad design decision to have constant set of input values, e.g. for a select1 or of labels
... in general not constant/fixed set. not even a known set when written
... and for localization etc
... input and output ideally all you want
... but then need a methodology to say further things about that input or output
... which depends on device and other aspects
... e.g. maps

John: how do we get to cluster of topics we have pending?
... how offer a feature like allowing authors to add their own xpath functions? cross-platform way to do this
... maybe built from smaller xforms actions
... or different features around submission/model patterns for multiple page apps
... captures what people are trying to do with today's xforms that make it simpler

Steven: yes, packaging that we can't do in current xforms
... creating abstractions for the larger design

could use XBL again here to package XForms declarative markup in higher level patterns

Steven: sodoku example writing out binds 1 by 1...very hard without repeat in the model

John: looking at multiple pages working together to achieve the total app is another hard pattern today

this is an example of the hybrid client/server model i think

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

John: have something similar now with insert
... submission element is something which is invoked by something else, i.e. send

Steven: today, submission seems geared to large-scale constraint to manage relationship outside the form

John: starts to relate to structural calculate

Steven: relevance is like this...when condition relevant, drive an action like submission

John: that's true of all mutations

Steven: general picture should be to see things as constraints...update as a result of other changes. submission just a tool in this process

John: why can't we today use submission to apply within-forms?
... URI pointing inside current document

Steven: could be defined that way but sure no impl does that

Leigh: submit to submission vs. to instance

John: is there more interest in looking at current xforms and building up more extension points?

vs. analyzing and features in what we've seen doing in xforms?

Steven: pls explain

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

Steven: yes, agree

John: for MIPs, for example, to be able to define a new property, give name, give value. specify and query over that new value

Steven: or influence presentation based on that
... e.g. negative values

John: metadata for UI controls, hint help alert, these are really MIPs
... more about data than UI control

Steven: hint/help about model?

John: in the loan form the alert would be reflecting loan business constraints
... hint on that data is still what the data is...more info on that data...could be provided to any form control

Steven: hint/help more likely model based than UI based

John: just examples of things we currently have that could be better handled as MIPs
... would help integration with other technologies. using MIPs easier than markup
... e.g. data node is digitally signed
... we don't provide extensibility for applications to define their own metadata here

Steven: yes, these are all examples of coming from static form design and discovering more dynamic issues involved
... not just about forms

<nick> I also agree that extensibility could/should also be a theme for a future version

John: seem to be three themes: author extensibility,
... pattern characterization,
... feature broadening

<nick> dialogs

John: submission extensions (binary resources)
... ...discusses upload example of generalized functions
... we assume delivery of final result is a single step...upload "conversation" is multi-step w/server
... not sure if this is "feature broadening" or "pattern characterization"
... feature broadening is the way we achieve the result

<Steven> http://farm2.static.flickr.com/1155/557243244_cc92f3d9e5.jpg

Leigh: REST design of expressing stateful conversation would be to have support for URI-addressed temporary resources
... with declarative support for making that easy to express
... e.g. server-side persistence based on headers

John: that's the how vs. what
... we have some experiments here

Leigh: need to explicitly design for this for the web

<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

Leigh: vs RMI it's all procedure calls
... so don't agree that state rep is means to end...it's guiding principle. but need declarative way that's easy to use

John: three levels: what to build (themes?), how to design them, and in the middle the guiding principles
... Nick, agree...if we have a text area (input!) ...

Nick: yes, not only binding to first text node but more generally to subtree

John: +1
... these more composite bindings are like submit w/instance replace

Leigh: that's what was done for select

John: also submission instance replacement, defined in terms of insert/delete actions

and replace text in terms of setvalue

scribe: yet another extension could be that form controls could do more than setvalue if we can extend definition of "ref"

silverlight has transformation layer between model and view

Leigh: should we try to define abstract markup that then operates over silverlight and flex?
... e.g. as our runtime platform, vs the raw browsers

John: thought that's where we were going, but hadn't talked about integration of improved features into them as host language

Leigh: think ubiquity for silverlight and flex
... is there a way to start standards effort around consistent MVC architecture?

John: topic of targeting existing HTML authors is a different conversation from targeting flex/silverlight class apps

Leigh: yes, those who have already decided to target these more complex platforms
... and look for standardization

John: already a lot of committed proprietary work
... we'd need some significant seed members

Leigh: don't need browser vendor "permission"
... also Laszlo is in this space

John: for a couple of days now we've been discussing proposing a substantially new group/mission

Steven: still exploring this vs. rechartering forms group

John: focus on improvements of xforms in documents, and collaborative workflow patterns
... seem to be areas that are forward looking
... and then extension points
... conversations aren't about "forms" it's about business processes and total application story

Nick: sometimes we see forms in the context of processes sometimes not

- DRAFT -

W3C Forms WG Virtual Face to Face 04 June 2009

04 Jun 2009

Attendees

Contents

XForms 1.1 PR

Future work

Summary of Action Items

Scribe.perl diagnostic output