RWAB telecon, March 3 -- 03 Mar 2009

<wiecha> Agenda: http://lists.w3.org/Archives/Public/public-xg-app-backplane/2009Mar/0001.html

<scribe> scribe: John_Boyer

Charlie: reviews agenda, suggests discussing AC issue first
... Steven can you tell us a bit more about the structure/content of the meeting?

Steven: still very vague, still just day1, day2...

Charlie: We saw an agenda that said "Future of XHTML2/XForms..."

Steven: Only a draft; nothing confirmed. But Philippe heard I was going and added me to a panel

Charlie: Are there preparatory readings we could send out so people are refreshed on work we've presented in the past on ubiquity

Steven: Are you suggesting getting it sent out in the package of W3C materials?

Charlie: Any mechanism to alert people to the possibilities we convey.
... Maybe we should talk about those points, e.g. there is a cool way of supporting XML on the client
... And that this opens up possibilities of supporting XML vocabularies that we hadn't thought of supporting on the web anymore

Steven: I really think we need to take emphasis away from the web as being only HTML

Charlie: This is why I've been pushing ODF, XBRL etc.

Steven: This whole battle is about the browser vendors trying to take back control because they're being asked to do a lot of things they may not want to do, so they're putting everything into HTML so they don't have do support broader extensibility

Charlie: TimBL seemed quite excited about our approach at last TPAC

Steven: Shouldn't centralize all the power in one group and then saying anything that goes in the browser is in their group. We need design done by domain experts.

Charlie: What do others think?

John: Very pleased with progress of ubiquity in proving out that something like xforms can be delivered on the web, but have really also been advocating other presentational vocabularies like ODF and SMIL etc. to show that we can deliver W3C client technologies on the web without being limited by the browser vendors

Charlie: Need to solidify what markup vocabularies could really be supported. Also need to identify what are our pain points in delivering these technologies.

Jack: But the html group is really developing a closed operating system.
... our extensibility story goes against that
... you have to be careful to ask for an extension framework, not just specific extensions.
... Problem is that we already have that, namespaces in HTML, and we know what they think of that

Charlie: But there may be an API level we can talk about.
... Look at the decorator.js mechanism in Ubiquity. It has lots of browser differences to make that happen.

Jack: but we are still at the research phase. We can really only do xforms right now; as we work on SMIL I'm sure there will be pain points
... ubiquity loader is a candidate, but it is not mature enough to standardize yet
... we don't have a clear enough idea yet what a generalized decorator/loader should do

Charlie: But when is the time to open the conversation about using the browser in this way as opposed to closing it
... I guess you're saying that leave it at that because if we have a more specific list then it might be limiting
... Is that the consensus?

John: I like the idea of just presenting the general approach, but we need to mention a couple of examples just to give an idea what we're talking about

Jack: what ubiquity does now is use stuff like stylesheets to attach behaviors to elements.
... The big advantage there, over a loop on startup, is that stuff that is created dynamically after startup also gets the same behaviors.

Charlie: declarative creation of structure *and* behaviors

<Steven> XBL does the same too. If it ever becomes interoperable it makes our life much easier

Charlie: I pushed that (XBL) at TPAC to the point where Chris Lilley took a poll. response from browser vendors was interesting but not high on list
... Is there some politics around XBL. Is it the X?

Steven: It takes power out of the browser makers hands.

Jack: but how is that different from javascript

<jackjansen> Ad=o1gl

Steven: Well, I agree. But you have to code javascript. XBL makes things *a lot* easier
... Also, browser makers have a lot invested in CSS, but it's an old technology that needs to be replaced.

Jack: My problem with XBL is that any docs you can find on it as three levels of meta
... I have the *feeling* I could do wonderful things with it, but it's hard to tell from the docs

Charlie: I found the original XBL 1 docs to be compelling concrete stuff
... I thought this was the direction we were going to go with ubiquity

John: I thought MarkB said we would need to write an XBL implementation to get ubiquity to webkit anyway

Charlie: I found a javascript XBL implementation on the web. will post link after meeting
... the above would be a great takeaway
... More narrowly on the XHTML2 and XForms topic, some will ask who is using it.
... list market segments
... enterprise space, open standard office document space, embedded device controller space (xerox), consumer space (yahoo mobile)
... consumer mainly mobile device space, which is important
... Yahoo is positioning itself as intermediary between content provider and consumer (they factor out the complexities of device adaptation)
... That's a high value service, and XForms is a key technology from an authoring point of view
... OK but lets move on. We can address the topic of open versus closed browser

Jack update on SMIL

Jack: nothing in last two weeks

Charlie: Hey that's not 20 seconds

Jack: I ... haven't ... done ... anything ... in ... last ... two ... weeks

Charlie: will your UI elements be forms controls?

Jack: no
... a control inherits its relevance from the model

Charlie: Yes but then that means when the control becomes relevant, it gets an event xforms-enabled, which can make it start a player

Jack: I was thinking that each object would have a relevance object, and the implementation of that object would depend on the language.

Charlie: But why do that? The machinery is already there. Why not just declare yourself to inherit the control behaviors from ubiquity and you're done

Jack: Have to think about it. A practical reason is that I want to use the loader and decoration stuff from ubiquity, but right now I don't depend on the xforms implementation and I kind of like that

Charlie: Now we get to the point of asking how much backplane kool-aid Jack is willing to drink

Jack: Well, I kind of assume that the ubiquity substrate will be separated out from xforms, whereas relevance is xforms-specific

Charlie: But now we get to the question of what is xforms. We did an analysis of xforms and found that a fair bit of it was more backplane-esque
... not suggesting you turn to XForms UI controls like select1, but the MVC lifecycle and the concept of eventing is more generally applicable than just xforms.
... single node binding, nodeset binding, model item property notifications should be spun as a backplane technology

John: So the nodeset binding is an example where we're saying that the backplane is more powerful than just the decorator mechanism
... With nodeset binding, you have a declarative way of saying that more stuff needs to show up in the page dynamically, and then the decorator works with that to add the behaviors dynamically.

Jack: Want to make sure we factor out relevance to make it clear there are hooks.

Charlie: One packaging of SMIL as a MIP-aware control would be a good value-add, and could then help refine understanding of technical requirements for generalization
... Mark Birbeck would like to correspond with you, Jack, to talk about SMIL and its relationship to ubiquity. He sees it as a really good example to show the general approach we're pursuing.

<wiecha> http://www.xero.com/

Scenarios

A site that deals with data and sophisticated presentation of the same.

<Steven> It looks like an online Quicken

Charlie: Mark raised this site as a way to show richer graphics for ubiquity xforms, but it is also a good example of richer mediatypes and web services access
... So the scenario is a collaborative financial planning/tracking team room
... Multiple users members of a family, financial planner, backend services working together.
... Family has to make decisions, buy and sell

Steven: It's a really good scenario because lots of changes can occur declaratively based on what the user choose.

John: To use the buzzword, this is beginning to show the applicability of XForms to mashups.
... A regular mashup has spaghetti wiring. The architecture here is more hub and spokes

<Steven> Oh, regrets next week

<wiecha> k

<Steven> XHTML2 Vftf

<wiecha> np

<Steven> Also,

<Steven> I'm talking at Mozcamp NL this week

<Steven> on XForms

<Steven> will mention Ubiquity

<wiecha> cool...check with mark, he has an interactive talk

John: Different mashup components communicate with each other but they do so through a central model that is responsible for sending synchronization events (change update events) to the other compoents

<wiecha> done in the browser with live ubiquity examples

<Steven> good advice

<Steven> thanks

- DRAFT -

RWAB telecon, March 3

03 Mar 2009

Attendees

Contents

Jack update on SMIL

Scenarios

Summary of Action Items

Scribe.perl diagnostic output