00:00:28 DA: Are you making this problem look simpler than it really is? 00:00:31 s/you/we/ 00:00:34 DA: Mobile guys want it to be simpler - can we making it simpler than the problems we have now. 00:01:03 MB: Java could solve the problem, but to clarify... 00:01:08 MB: Java can solve the problem 00:01:13 MB: Interoperability is very important. 00:01:27 MB: It would be fantastic to write an applications and deploy to multiple platforms. 00:01:50 MB: [compares to Pattern programming] 00:02:04 MB: I want people to use that type of approach forWebApps. 00:02:17 MB: Tax form is exactly the app you want to use a pattern for. 00:02:27 MB: few simple business rules. 00:02:58 MB: The Adobe VBS is just a heirarchical search pattern 00:03:13 MB: Would be good to have a simple declarative language for this. 00:03:22 MB: We are constantly reinventing the wheel 00:03:44 MB: HTML worked because of cut & paste. 00:03:54 and view source 00:03:59 MB: How can we cut and paste a visual search? That's what we need. 00:04:18 Laszlo guy suggests MB look at LBX 00:04:23 LZX ? 00:04:30 LZX it is 00:04:36 whatever :) 00:04:36 Lots of talk about languages, nothing about runtimes. 00:04:54 Laszlo guy's name? 00:05:04 Laszlo: Java has not taken on the client. 00:05:06 "We love runtimes" 00:05:32 Laszlo: What's the loading order? 00:06:03 Laszlo: We need to define the runtime. This is what XAML/.NET will do, but it is Windows only. 00:06:11 John Boyer - PureEdge 00:06:37 John Boyer: we have Java now - a quick case study 00:07:51 JB: we did an application that uses declaritive mark-up, we compared declaritive to what they could build in house, the demo app - the in house spent a day saying it would take a month to give an estimate - the declaritive solution was implemented in a day. 00:08:56 MM: Java didn't work on client because it was too slow. It is still too slow. 00:09:16 Matt May - the javascript player is adding weight to make it too slow. Why not put this functionality into the player. 00:09:48 [I'd say because then the web-app authors loses control, we're constrained to what we're given, with script we get what we're able to produce!] 00:10:01 AH: CLI is an ECMA Standard 00:10:05 [334 IIRC] 00:11:16 as with most languages, the libraries rather than the language provide the real value 00:11:50 AH: People have created a fragile platform when you get advanced systems... 00:12:45 AH: getting features to a high quality is tough in declaritive situations. 00:14:03 AH: we can get to 80-90% before you need script. 00:14:12 AH: in form applications./ 00:15:18 hakon lie: Java would've been a clean model, but it didn't work out - javasript won. 00:15:21 [Hurrah!] 00:15:42 HL: We hate javascript as much as everyone else here. We can right neat javascript. 00:15:56 HL: Any spec W3 produces someone is going to abuse it. 00:17:07 TVR: a tax code is best implemented in declaritive since it's easy to author by tax code guys rather than programmers. 00:17:33 TVR: Focus on the data. 00:17:49 sac has joined #workshop 00:18:24 Peter ??? Adobe PDF manager? 00:18:31 Vincent Hardy: Java is a failure on the desktop - but it's on most phones. 00:18:39 Kandaces I think klotz 00:19:17 VH: Java is available on many clients - there's a JCP program to ensure it's available and the same on different platforsm. 00:19:33 VH: API is very complicated! 00:20:07 Kacandes 00:21:47 Stever Zilles: What are the 5 things we need to focus on to get something better than we're at now, and how much better to we need to be? 00:22:52 Josh France Telecom: Java on phones isn't really usable because they have to be written differently for different phones, we need more layers in there, to cope with different screen sizes and capabilities. 00:23:20 Matt May: Sorry for giving impression Java was a failure... 00:24:05 MM: With the beginning of the web we took a deep breath - we now can't breat in any more, we need to breathe out and in again, get the new things the body needs. 00:24:30 MM: We need to ensure the people who are developing the web need the tools we need. 00:24:54 How do we get XHTML into IE? 00:25:44 that was IBM's Rich Schwarzfegger 00:26:25 .... existing HTML - not XHTML - existing infrastructure (ie, no new stuff) team is busy with security stuff 00:26:35 AHL we'll see how things pan out... 00:27:42 Rich: How do we get MS to address it - they're not in the WG for XHTML. 00:28:11 Tantek: We are in the XHTML WG, but they aren't doing what we want... 00:28:21 TC: proorities at MS are HTML4 eratta and a revised spec - not XHTML 2 00:28:43 SP: But that is your action item 00:29:28 TC: Where's the test suites, errata's etc. 00:29:37 TVR: Shouldn't you be doing this TC... 00:30:00 dino: bringing us back on topic... 00:30:26 Daniel, Sun: Any solution that we come up with that meets todays requirements will be really complicated. 00:30:44 David Temkin, Laszlo 00:31:19 David Temkin Laszlo: I agree things are complicated, but web-apps are a much smaller set than people are suggesting. We need an incredibly reliable RISC machine. 00:31:21 rrsagent, pointer 00:31:21 See http://www.w3.org/2004/06/02-workshop-irc#T00-31-21 00:31:30 DT: we don't need photoshop as a web-app. 00:31:58 Bert Bos: Most things are too simple for Java. 00:32:17 BB: Isn't the only reason java isn't used is that it's too much like a real programming language? 00:33:04 Steven: note that XHTML 1.0 didn't even describe how it should be implemented until well after it was a REC: http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html 00:33:13 Steven: and that isn't even in a published document yet 00:33:29 Steven: so the core of how XHTML1 is to be implemented depends on a post to www-html 00:33:43 Steven: (which is pretty ridiculous imho) 00:35:55 Paul Topping, Design Science 00:36:06 MB - XForm like things normally get implemented again and again by huge teams. 00:36:35 PT: Every real declaritive application runs into a break wall that ends up needing imperative languages. 00:36:38 PT++ 00:37:11 so do what you can declaratively, and solve the rest with script 00:37:20 PT: declaritive folk seem to want a simpler world than reality... 00:38:04 TVR: declarative allows the amount of imperative code to be reduced, goal is not to eliminate it entirely 00:38:22 TVR: use the scripting experience of the past to move into declaritive systems. 00:38:30 Steven noted that we should factor out the most common tasks, such as dependancy graphs, into declarative 00:40:31 Sun guy Java's hard to write, however that doesn't stop us writing applications in an easier way that runs on top of java 00:41:10 Chet Huss, Sun? 00:41:48 Leigh Klotz - Maybe what we should be doing is XHTML+CSS+SVG+XForms client in Java, CLR, maybe flash. 00:42:05 sort of like XSmiles, which already exists? 00:43:04 John: if we wrap javascript into a VM is that good enough - no since we need rules in the declaritive forms, rather than imperative rules. 00:43:19 seems that declarative is "safer" than imperative 00:44:57 We're winding up now... thanks to everyone... and we're closed. 00:45:50 Think about next steps over dinner. 00:46:08 AntoineQuint has left #workshop 00:54:02 robin has joined #workshop 01:42:26 bjoern_h has joined #workshop 05:00:46 Hixie has joined #workshop 05:03:23 bert_lap has joined #workshop 05:15:33 dbaron has joined #workshop 05:18:27 Hixie has joined #workshop 05:19:59 Tantek has joined #workshop 05:26:43 tanteko has joined #workshop 05:27:46 hello 14:51:37 RRSAgent has joined #workshop 14:51:44 rrsagent, make logs world-access 14:51:51 thanks buddy 15:41:11 JibberJim has joined #workshop 15:42:42 Hixie has joined #workshop 15:43:23 dbaron has joined #workshop 15:43:43 AntoineQuint has joined #workshop 15:44:31 schepers has joined #workshop 15:47:55 bjoern, should be worky now 15:48:04 yes, it does, thanks 15:48:16 Dave has joined #workshop 15:48:18 it seems that rrsagent doesn't listen to me 15:48:33 That's fair though, neither do the rest of us. 15:48:41 hehe 15:54:04 mimasa has joined #workshop 15:57:53 schepers has joined #workshop 16:03:45 bert_lap has joined #workshop 16:04:03 Steven has joined #workshop 16:04:11 heycam has joined #workshop 16:05:26 tvraman has joined #workshop 16:06:14 MDubinko has joined #workshop 16:11:16 Good Morning, and welcome to day 2. 16:12:07 RRSAgent, pointer 16:12:07 See http://www.w3.org/2004/06/02-workshop-irc#T16-12-07 16:17:29 Chris has joined #workshop 16:17:31 Good morning, JibberJim and everybody. 16:17:40 jrandall has joined #workshop 16:17:40 good morning 16:20:23 robin has joined #workshop 16:20:38 who is running this show? 16:20:42 what a mess~ 16:20:44 ! 16:20:56 Steve Zilles asked what would mean that WebApps/CompDocs had gotten good enough to make a difference 16:21:32 jrandall has joined #workshop 16:22:07 a possible answer - that there were authoring tools generating something that worked on multiple implementations 16:23:41 Schepers: It will be a success when people who were writing HTML in 97 are doing it. 16:24:03 Patrick Smitz: People don't have apps to say, they have things to say. 16:24:21 ChrisL: Users may want to produce apps that do something! 16:25:24 ChrisL: There's something more than interactive documents that people would want to provide, even without being a complete programmer. 16:25:51 CL: people may want to produce small apps that are more than 'interactive documents' but less than 'full blown programs' 16:26:10 Schepers: Webapps today are more complicated, but they could be small componentised reusable widgets that you can tie together. 16:26:32 Glen, Ideaburst: Code's crap but people use it, tools could exist that people can create webapps. 16:27:45 G, I: We spent most of our time on interface rather than creating applications. 16:29:28 John Boyer, Pure Edge: Spreadsheet users aren't programmers, but they use declaritive stuff to do a lot of stuff. Point+click design folk are cheaper than programmers. 16:31:32 I agree with John and he made my point better than I did 16:32:05 shayman has joined #workshop 16:33:14 Widgets we make are generally slow if we have to wack them all in script, and are Device dependant, a standard can obviate these needs. 16:33:51 ^ That was Glen from Ideaburst 16:34:46 Teppo Jalava 16:35:48 TJ: shows SMIL/XForms - mixed docs are hard to read! 16:36:20 TJ: Timesheets are like CSS for temporal layout. 16:37:44 klotz has joined #workshop 16:38:15 TJ is demoing an app using a timesheets impl. in X-Smiles 16:41:08 Patrick Shmitz: Have you thought much about applying timesheets in compound docs and the issues? 16:42:11 MarkBirkbeck: Is CSS tied to the timesheet? Can you change more than just display? 16:42:21 PS: Yep you can change classes. 16:42:31 TJ: Yep you can change classes. 16:44:30 ChrisL: This is similar to something floated for DVD's XSS, what's the syntax? 16:44:36 TJ: XML/SMIL like. 16:45:11 Hixie: cites http://www.w3.org/TR/css3-preslev 16:45:17 IH: CSS WG has been looking at this in CSS3 16:46:37 Erik Henmann on behalf of OASIS. 16:46:53 EH: data standard for compound docs 16:48:07 EH: DITA - Darwin information typing arch. 16:48:31 Tantek has joined #workshop 16:49:07 EH: Granular/ strongly typed / referential - topics have semantic relationships, originally developed for software user assistance - useful for human readable content with formal definitions 16:55:15 ph has joined #workshop 17:02:19 Michael Pediaditakis 17:02:25 University of Kent 17:02:34 Slides at: http://www.w3.org/2004/04/webapps-cdf-ws/slides/kent-slides.pdf 17:03:30 Proposing a Generic XML Presentation, see the slides! 17:10:28 alt and case look like smil switch, except for batch preprocessing 17:11:19 I like this, very much agree with "declaritive layers implemented imperatively" 17:14:11 tjjalava has joined #workshop 17:16:33 Paul Topping - Design Science 17:16:38 showing MathPlayer 17:16:40 On MAthPlayer 17:16:43 no slides online yet 17:16:58 PT: It demonstrates some of the problems of plugins etc. 17:17:26 uses MS behaviours, DOM and loads of other interfaces in IE. 17:19:01 PT: very loud speech reader of the MathML content. 17:19:27 PT: means the screen reader or search needs to get through the multi-layers of the system. 17:20:09 PT: Ideally we want to implement mathplayer in all browsers using standardised interfaces. 17:20:51 PT: Mah is more complicated than the regular "include an image" as we need to place it appropriately sized within the paragraph, need comms between the HTML/MathML rendering layers. 17:22:40 PT: We need to indicate to server the capabilities, can the player not only implement MathML, we need to know it can maybe play it or whatever. 17:23:01 tjjalava has joined #workshop 17:23:27 [I disagree, we're never going to get anywhere if we cabal-ise the web, authors can maybe make allowances to support bugs in a couple of major UA's, they can't author docs for every single player.] 17:24:08 Dan has joined #workshop 17:24:42 PT: MathML is a good use case for compound docs - you can't just display it as a picture, you need to search in it etc. 17:25:40 PT: Let's not start on XForms and XAML without learning from the past. 17:26:06 PT: Support for XML is not enough, need to allow support multiple vendors 17:26:29 PT: We need a cross-platform runtime, but don't look to a hardware vendor. 17:36:55 Steven has left #workshop 18:00:21 jrandall has joined #workshop 18:02:49 Steven Pemberton on XForms 18:03:07 SP: More impls on day of release than any previous W3 spec. 18:03:25 SP: Lots of users, lots of vendors. 18:05:53 SP: data is one or more XML docs, input/output/memory model etc. 18:06:11 SP: Abstract input/output controls, impls can style it, or bound to SVG or ... 18:07:30 SP: Imperative vs declaritive - in 80's developed several clocks which had different views 18:07:42 SP: the shortest analogue clock in imperative was 1000 lines. 18:08:04 [it would be less than 10 lines of javascript in SVG] 18:08:51 where javascript = standards-compliant DOM scripting 18:08:54 SP: Shows simple ticking clock code. 18:09:10 Yes AntoineQuint 18:09:17 naviuser has joined #workshop 18:09:18 SP: Some XForms impl just have the model. 18:09:29 Jim, don't use the javascript term so much, people tend to think of the broken APIs and practices burried behind it :) 18:09:30 SP: CSS or SVG for the impl, no commitment 18:09:50 Sorry Antoine, but I still want to make it respectable... 18:09:57 "ECMAScript" 18:10:21 SP: DI, Accessible, mostly declaritive but can be imperative. 18:10:23 C 18:10:24 JibberJim: I agree it is! 18:10:38 C# is also an ECMA Script language though bjoern now. 18:11:43 SP: Demos a couple of XForms examples 18:12:40 Paul Topping - design topping: Your rendering of one of the examples is poor? ... 18:12:53 SP: XForms is independant of the rendering 18:13:02 SP: CSS 3 and SVG will address this. 18:13:30 (Well. CSS1 addressed the baseline issue back in 1996...) 18:13:41 Cameron McCormack: Can you effect things other than the XML model, e.g. CSS or positioning? 18:14:05 So it was a non-conformant CSS1 implementation in IE there Hixie? 18:14:16 just use SVG :) 18:14:23 JibberJim: i'd have to look at the exact markup to say, but yeah, probably 18:14:36 SP: Yep, but it's not really what it primarily designed for. 18:14:58 JibberJim: it might be one of the undefined edge cases (form controls aren't well defined right now, as SP said, CSS3 is addressing that better) 18:15:26 clock: it would also be less than 10 lines of declarative code in SVG, not just script, JibberJim 18:16:17 John Boyer is demoing some games in XForms. 18:16:59 JB: Wizard like data entry for tax forms. 18:17:24 schepers: you can't do the clock just declarative (I think) 18:17:59 there's an SVG analog clock on http://xmlfr.org/ fwiw 18:18:01 I think you can as long as they load it at a specific time... 18:19:17 you may be able to use wallclock(...) to pretend your animation started at some point in the past and rely on the SMIL engine to compute where the animation should be now 18:19:26 JB: doesn't matter which form I'm editing, the model reflects changes everywhere. 18:19:49 JB: Wrap the most appropriate host/rendering language around the rendering. 18:19:56 er the model. 18:21:54 JB: XForm skins are what we want to control the presentation. 18:24:20 Kelvin from IBM: how are you rendering this? 18:24:38 JB: We're using the Pure Edge XForms renderer - a plugin to the browsers. 18:28:16 Micah Dubinko on XForms. 18:29:33 Steven has joined #workshop 18:29:55 shayman has joined #workshop 18:32:36 Do we have a link to XForms basic? 18:32:48 http://www.w3.org/TR/xforms-basic/ 18:33:24 Robin, you also mentioned a good intro doc to this? 18:33:26 HL: XForms spec is too complex. Authors will have a problem authoring XForms as it is now. Could we do something with the basic profile of XForms, remove namespaces, remove XPath? 18:34:10 ?? (from IBM): What is that people are screwing up with namespaces? 18:34:18 I can't find it 18:34:24 Leigh ought to know 18:34:24 Too many to fit in your head. 18:34:26 MD: Namespace URIs are too long. More stuff than you can fit in your head. 18:34:29 Chris, another difference is that xpath is way way more powerful than selectors 18:34:50 MD: How XPath addressses Namespaces, doesn't use the default. 18:35:15 hmm, so if code size is important, throw out CSS and just use an XPath based selector styling system? 18:35:53 unfortunately that would mean that the web didn't render, so it's not a viable business plan 18:35:57 XPath in Java is 85K bytecodes. Do a google search. 18:35:57 (for a web browser) 18:36:28 well, didn't render so sweetly... 18:36:31 klotz: including dynamic DOM changes in the face of script? 18:36:51 (Spontaneous applause; only the second this meeting!) 18:37:15 JibberJim: I found something but unfortunately it's member only 18:38:19 how about an XPath Basic that has just the information contained in CSS Selectors? 18:38:31 then use straightforward conversion 18:38:31 klotz: (and does it implement the xforms extensions to xpath? note that mozilla's xpath implementation is more like 300k) 18:38:38 Dave Raggett: 18:38:44 björn managed the reverse very easily 18:38:55 DR: I'd like to break apps outside of the browser 18:39:03 DR: more various apps. 18:39:34 DR: cheaper, more flexible 18:39:41 DR: Easily adapted 18:40:26 DR: Author defined controls and Multi-modal interface 18:40:40 DR: Let people use their own XML 18:40:43 actually Mozilla's is 170K (elf32 binary) 18:40:52 (I just gave Ian an incorrect number a minute ago) 18:41:08 DR: Zinf demo - differently themed mediaplayer 18:41:50 DR: no chrome, windows irregular shaped 18:41:57 DR: Describe Object model in XML 18:42:28 DR: need way to close etc. 18:42:37 XForms validator is at http://xformsinstitute.com/validator/ 18:42:54 XPath in pure Perl is 39k, including complete docs and installer :) 18:43:05 DR: This is beyond XForms, split UI into an abstraction and to a theme for pres. 18:43:09 robin: and does _that_ work with dynamic DOM changes? 18:43:49 no idea 18:43:57 that's the hard bit 18:44:02 hence my proposal to piggy back the CSS code that does that 18:44:24 certainly using selectors instead of xpath in xforms would be an interesting thing to look into 18:44:30 but why is dynamically-updating XPath relevant to XForms? 18:44:34 DR: Layout intentions use SVG/XBL for delivering such controls, so we can create novel controls. 18:44:46 MDubinko: because the whole point of xforms is that it is dynamic? :-) 18:44:55 (XForms has an explicit reevaluate-XPath-now step) 18:45:07 DR: Layout delegated down to the layout manager rather than doing it all yourself. 18:45:14 I'd rather not have CSS Selectors instead of XPath in XForms 18:45:16 i looked at dependencies in xpath, to make sure expressions are evaluated when they need to be 18:45:16 DR: declaritive treatment of behaviour 18:45:27 it would require all Full implementations to support both 18:45:33 so drop xpath 18:45:35 it's not too difficult, but you do need to walk the path to work out which nodes are covered 18:45:36 DR: Simple event binding, state transition between named states. 18:45:54 you can't drop XPath, it's extensible 18:46:00 where CSS Selectors aren't 18:46:05 sure they are 18:46:15 mozilla and opera have both extended them 18:46:24 that doesn't quite count :) 18:46:28 why not? 18:46:30 DR: Could invoke methods or update data, or raise events. 18:46:32 well I know of no implementation in which you can plug in your own functions 18:46:39 that's an implementation detail 18:46:40 whereas XPath has that all over the place 18:46:49 no, it's also a specification detail 18:46:56 XPath supports it natively 18:46:57 (and in any case it is arguably one of the problems of xpath) 18:47:12 anyway xpath and selectors do different things 18:47:19 for example selectors has no equivalent of xpath true() 18:47:21 given a defined svg prefix bound to a namespace, I can add svg:bbox(foo) and it'll work 18:47:28 and can't do maths expressions 18:47:30 etc 18:47:32 right 18:47:38 DR: we can treat all input uniformally as events. 18:47:44 XPath is more an incomplete superset 18:47:52 DR: EMMA XML lang. for interpreted input. 18:47:55 it's just a different language imho 18:48:06 yeah but there's overlap 18:48:08 sure 18:48:20 selectors is about going from an element in a dom, and a selector, and telling you if it matches 18:48:27 whereas xpath is about an expression language that is dom-aware 18:48:28 overlap that should be consolidated so as to make things using either more implementable on small footprint targets 18:48:47 would have been nice if the xpath people hadn't reinvented the wheel, true 18:48:49 xpath for matching is just what is used in xslt 18:49:04 yup, XPath does matching 18:49:18 DR: Various stuff already going on, Voice Browser folk, DI etc. 18:49:20 DR: 18:49:22 DR: 18:49:26 well, it can return a node set, and you can examine the nodeset for membership 18:49:33 Hixie: either they're different languages and they haven't reinvented the wheel, or they're not and they have, but you can't say both in the same breath :) 18:49:33 which means you can do matching with it 18:49:40 DR: use xml for descriping apps not jsut data - XBL and XForms 18:49:44 Hixie: nope 18:49:48 that's a usage detail 18:49:49 DR: Layout interntions, and what else? 18:50:15 for instance XML::XPath has a matches(xpath, node) that doesn't work that way 18:50:18 robin: they invented a language which had overlap with an existing language (although slightly different goals) without working on that existing language 18:50:42 it reads the XPath "in reverse" as it were and tells you it matches 18:51:17 ok 18:51:29 Schepers: What can't XForms do - what more does it need? 18:51:29 so it in fact explicitly has some of the same goals in that case 18:51:40 in which case it really is reinventing (and extending) the wheel 18:51:48 not much point in going crying over split milk (provided there is any -- XPath does a lot more than CSS did back then or even now). Better look into convergence now 18:51:54 sure 18:52:21 don't really see much of a way to do that though, i mean the languages don't even have a compatible syntax subset 18:52:41 define the subset of XPath that is sufficient to express CSS 18:52:46 John Boyer: xml-sig, wrap it all up into a single doc is important 18:53:00 use that in things like XForms Basic so that CSS implementations are basically reusable 18:53:07 with minimal overhead 18:53:15 shayman has joined #workshop 18:53:23 robin: then what? the existing web (you know, those n billion documents i like to talk about) uses CSS selectors, and they aren't going to just switch 18:53:25 JB: ability to wrap attachments into the same underlying data. 18:54:12 Why would they need to switch? 18:54:18 Hixie: where is that a problem? they can keep using it. Point is that XForms can keep using XPath (so that there isn't a kludgy "two languages supported here") and be implementable easily on mobile 18:54:28 exactly, they'd never need to switch 18:54:52 SP: There's lots of more requirements coming in future XForms specs 1.1/2 etc. 18:54:54 robin: how does this help? Now you have a bunch of implementations that don't do full xpath, and those implementations will be continuously told to support full xpath. 18:55:11 it's just a smaller profile 18:55:17 dino: it's off topic for web apps imho 18:55:25 ok 18:55:39 robin: but as you know, i think profiles are bad :-) 18:56:00 yeah, but I still have to hear an argument on that one :) 18:56:11 david gave one in yesterday's presentation :-) 18:56:22 which I missed since I flew in late... 18:56:35 but we have lots of arguments on the positive side 18:56:35 ah. then see http://dbaron.org/www/df-frag 18:57:30 hmmmm 18:57:37 TVR: XForms has datatypes and abstract layers - rather than a presentation 18:58:29 that document conflates formats and profiles, I think that's stretching it 18:58:44 TVR: More stuff shouldn't be done in XForms, they should be done in another spec which says how to combine this all together to create webapps 18:58:45 i think the point is they are equivalent 18:58:56 (to authors) 18:59:01 I don't see it making claims supporting that point 18:59:10 *shrug* 18:59:20 and agitating XML Schema is too easy :) 19:01:48 SP: XForms is the intent of the structure, not the rendering. 19:02:45 CL: As soon as you bring in a host language you have different versions of the XForms packaged is it really of value? 19:03:44 SP: Yes we need a way to keep things seperate, but also need to package some how. 19:05:23 MB - XForms isn't perfect, but the missing things are mostly outside of the domain - how do we make a range control look like a thermometer when it's possible, but it can fallback to somethign else. 19:06:05 More about Dave's "layout intentions" to add to CSS: ideas about flexible "glue and springs" from XUL (http://www.damowmow.com/temp/csswg/old/ui/flexbox.html) and grid templates, simplified from the NOTE-layout draft (http://www.w3.org/Style/Group/css3-src/css3-positioning/Overview.html#template-based) 19:06:30 MB: example of an SVG map that lets you choose a city, but it not available, a dropdown list of cities is given instead 19:07:52 MB: Here's an XHTML 2.0 doc with XForms and then have it rendered in SVG or something. 19:08:40 thanks to the irc monkeys for scribing while Leigh is at the mic. 19:09:27 MB: we can start spreading events to different applications that reflect the model. 19:09:51 Peter from SE: XForms aren't on mobile devices because we're focussed on imaging and entertainment, no real use case yet. 19:10:37 Peter from SE: We would implement inputmode if it was its own spec 19:10:46 TVR: It is its own appendix! 19:11:05 Leigh Klotz: We're using XForms internally on lots of products. XForms+XHTML+XSLT works well on embedded 19:11:35