<jsalvachua> hello

<Charlie> hi !

<jsalvachua> good morning

aloha!

<Charlie> and good evening to you too...

<Charlie> Scribe: Gregory

<scribe> scribeNick: oedipus

GJR's scribe/IRC/Zakim cheat sheet: http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0114.html

<Charlie> Agenda: http://lists.w3.org/Archives/Public/public-xg-app-backplane/2008Jun/0002.html

<scribe> chair: Charlie

News & Notes

CW: new members - conversation with Steve Bratt - not to worry about dates in charter -- got a late start, not overly strict about that, have option to renew for another year; want to have deliverables by end of year, but perhaps can do more with broader participation
... intially formed out of non-GUI WGs -- Voice, MMI, etc.
... narrowly scoped objectives: prototyping AJAX libraries - if had more diverse membership might not be most obvious thing to do, but can reuse for MM apps; engage with them at plenary
... wiki setup

JB: team contact duty - for XG don't have staff contact

CW: elevate to SteveB?

JB: sysreq better place to send

CW: will hang off XG URI; same access control - publically readable, member postable

JB: write-access limited to group

Story behind Story on Ubiquity XForms

http://code.google.com/p/ubiquity-xforms/

CW: JB, a bit of context and background?
... AJAX library which could be a starting point; want to get list of things to begin prototyping; want to start in on this right away need shared sense of longer term objectives and external point of view

JB: ubiquity library came from a number of threads converging over time; in early 2007, Forms WG rechartered (and even before within MarkUp Domain) and TBL and SteveB encouraged me to do what could to promote XForms in actuality; wanted to see efforts on behalf of WG to build standard proactively - not build it and then let them come; focused on how to build prototypes that can help promote adoption
... doing something with it ourselves, rather than just specify
... RWAB conversation since tech plenary of 2006 -- Charlie, Kenny, MarkB did plenary talk; in 2006/7 had daylong meeting (URL in previous agenda announcement)
... what are compoenents needed to drive development; has to be done in a manner that guides web community
... XForms community calls; Mark Birbeck interested in building library that would offer the XForms capabilities to AJAX devs aNDnatively to markup authors; Mark very interested in Modularization; interested in creating on-ramps to tech so people can use what is needed
... been working to launch RWAB - want reference implementation for XForms 1.1 - can be used to move latest version of XForms forward -- point 1: get XForms 1.1 test suite conformance; library a new effort - fair bit of code from Mark and associates, needs work to complete; working within IBM to get clearance to work on completing XForms for IE and FF without plug-in
... next step: conformance and hardening of library; conformance into safari; need to get opera involved with XForms support
... that's the immediate 6 month plan; in parallell have Charlie's team more interested in m12n; refactor code - what is refactorization that is needed, what are break points?
... example: submission -- XForms submission processing model a huge thing - have data (in data module) know module has rules for determining what data is relevant to submission (counting on relevance model) - node by node validity needs validity module (also XSD, Schema, XForms constraint for run-time) - submission module assumes that all of that exists, dev left to own devices to put modules together; backplane effort is to allow submission module use w
... library as way of not just talking about work, but making it real for devs

CW: MarkB been spending fair bit of time on intermodule configurability - take subset of JS files from dojo and pull them up; granularity of what he is looking at is one degree coarser than that just outlined by JB

JB: something can address over time: start with module as black-box, then revisit to make useful for other modules which may entail breaking them down
... very event focused; if have to refactor submission, might make more sense for another module and then wouldn't matter if single model module or module that does relevance and validity in instances; other modules should respond to XForms submission event and introduce into content info so XForm can procede by getting bits from other modules

CW: processing model and life-cycle is the problem

JB: what is context information to be shared - our versions of interfaces and parameters

CW: gets above declarative versus comparative - shouldn't matter; gives level of abstraction across implementations;

JB: in XForms WG talk about angle bracketed code for XForms model and relevance and validity rules; ubiquity is implementing declarative markup using AJAX/JavaScript code; actual code that runs in UA talking to XForms submit context info would be JS code running on behalf of declarative markup that determines what is being processed; doing both

CW: code living at 3 levels: application level (declarative scripting visible to dev); middleware/infrastructure code (ubiquity - runtime needs of processing model); platform/low-level code (natively provided by app or OS); push things down 1 level from applications to middleware level; benefit: making imperative code apparent to dev - good intermidiate language to get leverage
... JS and GJR questions?

JS: understand the model

GJR: understand the model been doing lot of background reading

Technical Issues

CW: few ideas: if events are cornerstone of issue, maybe opportunity to do implementation to XML Events 2 as addition to ubiquity library - need to brainstorm on how to work with dojo and others with XML Events 2 - turn up technical problems; questions around XML Events
... UI end of things - custom control topic; if use UI aspects of XForms in dojo where multiple widgets, how to get a common binding layer
... JB's data model issue - subsets and modules in data model - XML data or formalize sub-components?

GJR: XML Events 2 and expert handlers (need to bind to external document) external listener events from XML Events 2

JB: XML Events 2 refer to multiple or single documents?

CW: interesting piece of infrastructure - didn't pick up on multiple or single
... XML Events 2 - advantage relative to XML Events 1 is ability to run handlers conditionally; XForms has it, XML Events 2 has it; ability to modularize will be contingent on that capability; don't want conditional events to overwhelm intended events
... not just a problem with XForms, but difference btw initial DOM and runtime-DOM that is a "shadow DOM" that run-time is aware of - ability to set up listeners in trees important - should be covered by XML Events 2

JB: XForms address that question by having lifecycle that event listeners pay attention to; whatever happens in shadow DOM, specify how to dispatch those events on original source document; abstract "where do shadow DOMs exist?" - specify what want to modify

CW: SMIL, XForms or Voice underlying principle - parent authored document can be registered

JB: XForms "repeat module" - very special case for XForms and places where stuff is missing; can't in XForms data layer user interacting with is a separate DOM, no way for author to listen to DOM

CW: XML Events could obviate that - need document qualifier in XML Events 2 - listen, expose and drive
... input for XML Events 2

GJR: http://a11y.org/uuc (expert handlers use cases)

CW: registration, deregistration, conditional -- doesn't sound like earthshattering - useful doing mashups doing this stuff with dojo?

GJR: dojo support for ARIA

CW: wiring in dojo that is ad hoc - XML Events 2 library might simplify without datamodel implied; coordination in general

JB: handler can be used to define bucket of events that can be run - not tied to forms only

CW: not aware of any issues about dojo needing HTML or XHTML document; can do XML Events 2 to run in HTML as well as XHTML documents
... variety of HTML and XHTML examples -- requirement or issue running XML Events 2 in HTML document

JB: lot of work being done based on infoset available from actual DOM so didn't matter how DOM created in particular

CW: mimetype - different properties between HTML and XHTML relevant?

JB: a lot of code tests for existence of certain objects than branches accordingly

CW: support for library

JB: yes

GJR: yes

JB: same mandate as dojo - should figure out how to work when not operating over XML document

CW: XML for tag soup :)

JB: XML Events 1

CW: not there - abstract expression of DOM events, but not actual XML elements supported at this point in library
... code for all attributes there
... might be good kick start

JB: think so too

Custom Control

JB: done a lot of thinking about data model, want to do same to glue together presetations people want to create

CW: what programming models to expose to authors?
... Mark and i debated the following: AJAX community creates arbitrary widgets attached to a DIV using script with either addtional internal markup or more scripting; design patterns emerging - code behind story - stuff that does elaboration of original source doc can be factored out, can be included, can be selected by ID or CLASS associated with DIV; mindset of dojo community
... interesting opportunity to get custom namespace - instead of DIV class="x" could bind MyCalaner to data model - doesn't seem like developmental path for dojo - custom namespacing support not available; bind to external script or expose XForms abstract UI elements directly to author and allow author to manage attributes which would extend concrete mechanisms for doing rendering of XForms
... extend dojo widgets themselves via sub-classing but still could be authored in way comfortable for AJAX devs; inside or outside

JB: need a couple of whiteboard pictures :)

CW: strategy for viewing dojo for backplane; do we want to change the up-level authoring or cover what already know how to do

JB: better adoption if attach to what they want to do in shorter term, but that is a non-technical decision
... would be nice to have example: here is what would look like if dovetail with dojo practice; here is what would look like if done "right"
... compare on list

CW: MarkB proposing XForms UI elements become container elements (XBL-type) child elements that host particular implemetation logic, but don't need to be drivven by backplane; backplane digs deeper to find whatever hookups are required to drive dojo widgetry; could be available to us without modification
... flip side: everything in dojo that needs this functionality, would have to add objects from a standard library; change is positive from current practice -- more abstract elements

JB: new elements as wrappers for existing dojo constructs rather than attempt to inject markup into expressions used to create dojo widgets

CW: used your example as inverse: hosst language in XHTML elements used to wrap around INPUT

JB: reason wrap presentational langauge elements around XForms -- what allowed me to do that was complete control over presentational language; we don't control what dojo or other presentational languages do -- key reason for flipping argument around
... others asked me why not put XForms elements on outside and use XForms extension inside to define behavior - sounds like what MarkB proposing
... presentational elements from host language key on events that experience capture and bubble phase through host element, better XML Events library possible for extention to listen to events coming to XForms controls - if presentational content inside, code inside would say listen to code 2 levels above me - same result

CW: hadn't thought of that - if did that, could allow current dojo DIV attribute model to continue, while introducing standard event library

JB: something that contains event, set up listener - use exention mechanism great; only place breaks down with repeats (dynamic presentational content) - limitation of XForms repeat right now (XForms repeat contains an attribute called nodeset which binds to as many nodes of data an XPath expression can identify; will create copy of relevant repeat; XForms UI plus XHTML elements gets repeat for each node of nodeset - collection of repeated things (no easy

CW: repeat versus recycle

JB: capable of repetition, but needs another wrapper element around it that is controller of repetition - inside of me can put low level repeat and extention

CW: great call - XML Events 2 stuff straightforward to get working on - custom UI and dojo; have Forms face2face next week -- ok if skip next week and return on 17 june 2008

RESOLUTION: next RWAB XG call will be held on 17 june 2008

CW: will put some followup on list

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/elemetns/elements/
Found Scribe: Gregory
Found ScribeNick: oedipus
Default Present: Charlie, Gregory_Rosmaita, John_Boyer, jsalvachua01
Present: Charlie Gregory_Rosmaita John_Boyer jsalvachua01
Regrets: Uli Kevin
Agenda: http://lists.w3.org/Archives/Public/public-xg-app-backplane/2008Jun/0002.html
Got date from IRC log name: 03 Jun 2008
Guessing minutes URL: http://www.w3.org/2008/06/03-backplane-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.