See also: IRC log
<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
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
-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
+1
<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]
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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/update/updated/ Succeeded: s/coc/co/ Succeeded: s/are/being/ Succeeded: s/sork/work/ Succeeded: s/nant/ant/ Succeeded: s/developers/people/ Succeeded: s/to day/today/ Succeeded: s/spcs/specs/ Succeeded: s/at at/at a/ Succeeded: s/rich/mvc ubiquitously usable/ Succeeded: s/Sliverlight/Silverlight/ Succeeded: s/re-write it/provide alternative decorations for different platforms/ Succeeded: s/care/know/ Succeeded: s/Web Builders/Web App Builders/ Succeeded: s/taht/that/ Succeeded: s/recharting/rechartering/ Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: Steven Inferring ScribeNick: Steven Found Scribe: Leigh Found ScribeNick: klotz Found Scribe: wiecha Inferring ScribeNick: wiecha Scribes: Steven, Leigh, wiecha ScribeNicks: klotz, Steven, wiecha WARNING: Replacing list of attendees. Old list: +1.302.566.aaaa kenneth wiecha [IPcaller] John_Boyer Steven Leigh_Klotz nick New list: Leigh_Klotz Default Present: wiecha, John_Boyer, Steven, Leigh_Klotz, nick, kenneth Present: wiecha John_Boyer Steven Leigh_Klotz nick kenneth Regrets: Erik Agenda: http://www.w3.org/MarkUp/Forms/wiki/vFtF_2009_06_04 Got date from IRC log name: 04 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/04-forms-minutes.html People with action items: steven[End of scribe.perl diagnostic output]