See also: IRC log
<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
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
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
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
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.[End of scribe.perl diagnostic output]