Minutes, WIDEX Working Group, IETF 65 Recorded by Eric Burger Edited by Dean Willis 23 March 2006 Widex Requirements (Vlad Stirbu) ================================ draft-stirbu-widex-requirements-00 ACTIONS ------- Account for W3C REX requirements Will post -01 draft two weeks after IETF 65 Chair will review -01 for suitability for WGLC once draft is posted. Widex Framework (Vlad Stirbu) ============================= draft-stirbu-widex-framework-00 QUESTIONS --------- Carsten Bormann: It looks like you networked the View, and not the Model or Controller? Yes. Carsten: "Networked MVC" makes me think about Ajax. Dave: Ajax requires a lot of controller (scripting) logic in the renderer. The goal is to keep the renderer simple. Keep all of the application logic in the server. Carsten: Was looking for something that would work where the renderer has a intermittent connection to the server. Chair: Different design goal; we are not trying to solve that. Dean: Has OMA talked to us about using Widex for MORE (Mobile Open Rich-Media Environment)? Vlad: MORE work is essentially done. Dean (OMA Liaison hat on): Have we received any requirements? Vlad: No. Dean: Thus no need to do any liaison work. Transitive relationship: W3C knows about Widex, OMA knows about W3C, thus OMA knows about Widex. ACTIONS ------- Vlad expects a prototype implementation by July, running on Linux on a Nokia 770 (GDK+). Eric: Should the framework stand alone as an RFC, or get rolled-in to the protocol document? Vlad & Chair: No burning desire to publish as a stand-alone document, thus will roll it in to the protocol document. W3C REX (Dave Raggett) ====================== Remote Events for XML (REX) Compound Document Format group and Scalable Vector Graphics work group product Original goal: streaming updates to SVG to mobile devices QUESTIONS --------- Dean: Insertions are hard (see Slide 6 of REX presentation). What happens if you insert a table row in position 7 if there are only 5 rows? Dave: Work-in-progress. Dean: If the handset is implementing OMA stack, they will be implementing XML Patch. Vlad: REX is based on XML DOM, while XPATHops is based on full XML. Dave: Something to consider. Dean: Dave's presentation (slide 17) describes some suggestions for changes to requirements. Do we want to take them on? Suggestion: discuss the requirements and see interest. Dean: Can we have multiple Widex sessions between client and server? That would require more than just URI. Dave: Assuming single session. Need to document. Lisa: Strongly suggest making which DOM to modify explicit, not implicit. Dean: How to handle situation where W3C changes REX? We don't want to have to keep changing Widex every time W3C changes REX. Need a clear point of demarcation. Dave: Getting to it. Part of it is for us to bring W3C where we think it belongs, but only once we figure out what we want to do. Carsten: Why not use timed offsets? Dave: SMIL does that; we are looking for something with less granularity and complexity. Carsten: Server cannot know when client will actually receive document, so "future" events could really be in the past. Vlad: That is the way it is. If you use Widex, you need to be aware that this could happen. Eric: Phones have no clue what "the current time" is. There is no effective difference between the server figuring out what time the client thinks it is and the server just thinking in terms of time since session start. Dave & Vlad: Something to look into. Discussion: REX is a moving target. We need to decide if we want to base Widex on REX. We will be working with DOM, so want to leverage tools. However, REX also brings baggage. For example, REX assumes XPATH, not XML Patch. We need to nail down and agree to this if this is the way we want to go. If we chose something other than REX, it would look a lot like REX. +++ Consensus: Use REX +++ ACTIONS ------- Need to document cardinality of Widex sessions between client and server. Need to get clarity from REX folks on DOM3 and QNames. We could work around it by specifying namespaces as a separate attribute or element. Resolve open issues. Framework needs to address temporal issues w.r.t. rendering time (physics). Dave will find out REX folks' use case for timestamps. REX does not have the ability to copy the entire DOM subtree. Need to put this into requirements document and press W3C to fix REX. Need to do addressing (identifying session and DOM tree) in the protocol. Need to put this into the framework. OPEN ISSUES ----------- Need to review how marshalling from DOM events w.r.t. IDL will work. That is, how will we serialize DOM events? We cannot have all DOM events get transferred over-the-wire. Need to figure out how to specify what DOM events at the client get the server gets notified of. Is it by provisioning (i.e., this application has these events) or by negotiation? Should UI events that do not update the DOM get propagated via Widex or the application, such as input focus, text selection, cursor position? Vlad thinks they should be left out. Dave: Someone needs to deal with it, but it could be external to Widex. Vlad: Widex needs to communicate stuff that is relevant to modality. Dave: These are application events, not strictly UI events. +++ Put into framework document. Need to decide whether times should be UTC UNIX Birthday offset times or start-of-session offset times. Also, is the important thing "3 seconds from now" or "3 seconds from last rendering"? XPath expressions need a lot of specification to make them unambiguous. Who should specify that, Widex or REX? Need to dive deeper and work with W3C. REX has a specific set of events; we want to generalize to arbitrary events. We want to use REX mechanism but in an extensible method; we know we need more events already. Add requirement for not reporting all DOM events from the renderer. Discuss selection of which DOM events are relevant from the framework and Widex messages documents and discuss them. Proposal is that there will be no explicit subscribe / notify mechanism internal to Widex. Note that session establishment might pass parameters, negotiate events, etc., but that is beyond the scope of Widex.