15:22:31 <RRSAgent> RRSAgent has joined #workshop
15:22:40 <dino> rrsagent, make logs world-access
15:22:50 <dino> rrsagent, where am I?
15:22:50 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T15-22-50
15:34:09 <JibberJim> JibberJim has joined #workshop
15:37:44 <schepers> schepers has joined #workshop
15:41:46 <Hixie> Hixie has joined #workshop
15:46:27 <dbaron> dbaron has joined #workshop
15:55:59 <klotz> klotz has joined #workshop
15:56:50 <Hixie> dino!
15:57:04 <klotz> klotz has joined #workshop
15:57:13 <Hixie> dino: http://www.w3.org/2003/02/W3COrg.svg has the wrong attribute for "xmlns"
15:57:26 <Dave> Dave has joined #workshop
15:57:27 <Hixie> dino: the fact that it worked in any UA at all is a rather serious bug in whatever UA it worked in
15:58:20 <mimasa> mimasa has joined #workshop
15:58:35 <junior> junior has joined #workshop
15:58:52 <Hixie> testcase: http://www.hixie.ch/tests/adhoc/svg/error/004.xml
16:00:15 <JibberJim> Is anyone going to log to here?
16:00:29 <junior> Excellent question Jim, I sure wish someone would
16:00:34 <Hixie> oh look, a bug in the Adobe SVG plugin
16:01:10 <JibberJim> Well I would say sensible error correction in response to an invalid document.
16:01:17 <Hixie> it's not invalid
16:01:26 <Hixie> it's a perfectly well-formed and sensible XML document
16:01:30 <Hixie> with no SVG involved
16:01:58 <JibberJim> except it being served as image/svg+xml
16:03:20 <tvraman> tvraman has joined #workshop
16:03:30 <JibberJim> I also wouldn't say it was a sensible document in that the root elements aren't in any namespace.
16:03:32 <Hixie> if i don't serve it as that, the SVG plugin doesn't try to look at it
16:03:59 <Hixie> (which is another bug)
16:04:02 <JibberJim> no it's not!
16:04:12 <Hixie> RFC3023 says it is
16:04:25 <Hixie> RFC3023 says any XML mime type is equivalent as far as XML processing goes
16:04:34 <JibberJim> you can choose to pass off application/xml to that plug in handler should you wish.
16:05:05 <JibberJim> For XML processing - sure, but that doesn't mean it has to be rendered.
16:05:12 <Hixie> whatever
16:05:51 <JibberJim> It's non-conformant yeah, but it's more useful than the alternative.
16:06:50 <bjoern> rrsagent, pointer
16:06:50 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T16-06-50
16:07:16 <bjoern> dino, could you set the permissions again?
16:09:07 <bjoern> thanks
16:11:05 <JibberJim> dino - Workshop purpose?
16:11:49 <JibberJim> dino - Introduces various people...
16:12:44 <JibberJim> ah, there will be minutes...
16:13:44 <JibberJim> going over http://www.w3.org/2004/04/webapps-cdf-ws/agenda
16:14:37 <Steven> Steven has joined #workshop
16:14:55 <JibberJim> Bert to speak
16:14:55 <klotz> I am taking minutes now and will not be monitoring the IRC channel but will link the log in from the minutes when published.
16:14:58 <SteveZ> SteveZ has joined #workshop
16:15:06 <ScottH> ScottH has joined #workshop
16:15:10 <Rich> Rich has joined #workshop
16:15:26 <JibberJim> Bert's going to wake us up... 
16:15:29 <CY> CY has joined #workshop
16:15:58 <Mark> Mark has joined #workshop
16:16:08 <JibberJim> BB - HTML is in danger again! I'm here to save it again.
16:17:13 <JibberJim> BB - We've got CSS - but take-up's not been quite as fast as we like, but it wasn't enough.
16:17:20 <Dan> Dan has joined #workshop
16:17:35 <heycam> heycam has joined #workshop
16:18:04 <JibberJim> BB - javascript was the worst invention ever - at first we thought CSS could've replaced it, but no.
16:18:24 <dino> rrsagent, make logs world-access
16:18:25 <JibberJim> BB - Java is not simple enough for easy progs.
16:18:33 <dino> rrsagent, where am i?
16:18:33 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T16-18-33
16:19:28 <JibberJim> BB - We need a new scripting language to seperate logic from the UI - make progs portable DI and accessible, re-usable etc.
16:20:11 <schepers> [DI == device indepenedent]
16:21:04 <JibberJim> BB - We could start from scratch do the 80% with this new language and leave 20% with java - we could took 2 years...
16:22:23 <JibberJim> BB - What could it be like?  App/UI seperate - change the UI without changing the logic. accessed over telnet/web/phone etc.
16:22:57 <JibberJim> BB - Easy high level interpreted prog. lang - a bit like Ruby    and ...
16:23:24 <JibberJim> BB - An easy, high-level, declaritive UI language - (something like Gist?)
16:24:46 <JibberJim> BB - Just now need to work out the details...
16:25:30 <JibberJim> BB - Slides will be provided on-line at some point...
16:26:35 <JibberJim> Question from John somebody-or-other - have you looked at X-Forms?
16:27:17 <JibberJim> BB - I'm not sure, they could be part of the UI but they only seem good for forms rather than applications I'm imagining - works badly for games, or editors.
16:27:55 <JibberJim> Mark Birbeck now
16:28:05 <JibberJim> MB - In defence of X-Forms
16:29:18 <dino> John Boyer - Pure Edge asked the question
16:29:21 <JibberJim> MB - web apps can be client-side or anywhere - just using light-weight features of the web, not necessarily served over web, could be on desktop.
16:29:38 <JibberJim> thanks dino.
16:30:10 <dino> no, thanks to you for scribing
16:30:11 <maxf> maxf has joined #workshop
16:30:24 <Chris> Chris has joined #workshop
16:30:29 <JibberJim> MB - The browser could be a web-app itself.
16:30:43 <Chris> state transfer - /me thinks 'REST'
16:30:47 <JibberJim> MB - Are we too browser focussed?  Do we want to keep extending the browser?
16:31:18 <JibberJim> MB - How do all these plugins talk to each other - this is a wrong paradigm should be talking about wider things.
16:32:33 <JibberJim> MB - shows X-Forms UI.
16:33:25 <JibberJim> MB - We need to try and address seperating renderer out to standardise interactions between rendering.
16:33:35 <JibberJim> MB - we need two DOM trees, a rendered and a semantic one.
16:33:59 <JibberJim> MB - Standardise locations for toolbars system tray's etc.
16:34:44 <Chris> parallel voice and visual rendering  - multimodal
16:35:00 <sarah> sarah has joined #workshop
16:35:39 <JibberJim> MB -  Augment the infoset - enables serialisation to save and resume and agents etc.
16:36:17 <JibberJim> MB - 
16:36:25 <JibberJim> MB - We're taking too long CSS is enormous!
16:36:38 <Hixie> as opposed to xforms? ;-)
16:36:52 <JibberJim> MB - We need to break everything down into tiny compartments.
16:36:58 <JibberJim> :-)
16:37:20 <bert_lap> bert_lap has joined #workshop
16:37:25 <JibberJim> MB - more compact specs.
16:38:27 <JibberJim> MB - whether it's a browser doesn't really matter?
16:38:51 <JibberJim> MB - We've got lots of renderers MSagent/browsers/ASV - need a cleaner break.
16:38:53 <schepers> once we have working models, for instance, we could break out file access and such from SVG (post1.2)
16:39:21 <JibberJim> Q - Your paper discussed a Virtual Machine...
16:40:27 <JibberJim> MB - We have a DOM, we layer on rules, schema languages etc. - when you add all this together we can call this a virtual machine, which we know about, so we can move state between machines.
16:40:36 <JibberJim> Matt May from W3C to now talk.
16:40:46 <JibberJim> MM - Ladybird on the screen.
16:40:50 <JibberJim> MM - I broke the web!
16:41:51 <JibberJim> MM - In the beginning - I pushed the envelope HTML, people had certain requirements, no bandwidth, weak UAs made a doc. format to a web-app platform.
16:42:38 <JibberJim> MM - Added cookies we needed state.
16:42:56 <JibberJim> MM - we got a really poor system - script+screen readers = broken.
16:43:26 <JibberJim> MM - We need DI events.
16:43:58 <JibberJim> MM - Poor semantics with FONT etc.
16:44:58 <JibberJim> MM - 1000 ways to do something - how do we know what you're trying to do?  how can we determine what a script can do?
16:45:17 <JibberJim> MM - EEK! cookies, script!  users come into control, and they choose to use something else.
16:45:30 <JibberJim> MM - HTML+DOM+JS what it does:
16:45:37 <JibberJim> MM - change state/style/position.
16:45:43 <JibberJim> MM - Forms validation.
16:45:47 <JibberJim> MM - Generate HTML.
16:45:55 <JibberJim> MM - Bind elements to one another
16:46:02 <JibberJim> MM - Raise new windows.
16:46:14 <JibberJim> MM - manufacture new UI elements
16:46:22 <JibberJim> MM - Execute server transactions
16:46:30 <JibberJim> MM - Reload and set timers.
16:46:36 <dino> 2nd Question in Mark's talk was from Philipp Hoschka - W3C
16:47:25 <JibberJim> MM - Most of this can be done declaritively - XForms can do validation.
16:47:26 <tvraman> Almost every one of these problems is fixed by XForms with clean declarative solutions that are accessible out of the box
16:47:54 <JibberJim> MM - What do we need from accessibility?
16:48:20 <schepers> but XForms isn't a visual layer
16:48:26 <JibberJim> MM - everything in 1 package, fragmented approach is inaccessible
16:48:43 <Steven> Steven has joined #workshop
16:48:47 <schepers> (not that a visual layer is all that's needed)
16:48:53 <JibberJim> MM - AT developers don't have the resource
16:49:11 <JibberJim> MM - Just beginning WCAG JS techniques.
16:49:20 <Steven_> Steven_ has joined #workshop
16:49:24 <JibberJim> (well we had a draft 2 years ago...)
16:49:58 <JibberJim> MM - a DHTML roadmap XHTML 2.0, XForms CSS 3 DOM 3 L+S
16:50:17 <JibberJim> MM - new Web-app architecture - XUL/XAML/Flex etc.
16:50:32 <JibberJim> MM - we need to get as close to one model as possible.
16:51:43 <JibberJim> Rich from IBM - 2nd roadmap, XHTML 2.0 concepts can be applied to XHTML 1.1
16:52:05 <Chris> dom2 makes all elements active but they can't get focus
16:52:26 <JibberJim> Rich from IBM - Div and spans can't be given focus but are used, this is an important thing we want.
16:52:40 <Chris> (seems to want that for second order collections of elements made to be 'a UI element')
16:52:43 <Steven> (Rich Schwardtfeger)
16:52:49 <Hixie> sounds like xbl :-)
16:53:08 <Chris> David Baron.Mozilla Foundation
16:53:29 <MDubinko> MDubinko has joined #workshop
16:53:30 <JibberJim> Dave Baron - Some of these Acc. probs are related to screen readers on top of visual browser?
16:54:05 <JibberJim> DB - How much have you looked into what happens when you're not using a visual -based AT but direct to Audio pres for example.
16:54:37 <howcome> howcome has joined #workshop
16:55:36 <JibberJim> MM - The key is that the browsers roll is to expose the DOM to the user, we don't have semantic docs at the moment for webapps.
16:55:44 <JibberJim> Moving on.
16:55:57 <JibberJim> Vincent Quint - Editing compound docs.
16:56:35 <JibberJim> VQ - Our experience with Amaya
16:56:50 <schepers> and audio is not the only issue... what about automation?
16:57:02 <JibberJim> VQ - nesting multiple mark-up langs - edditing nodes style etc.
16:57:34 <JibberJim> VQ - severel levels of embedded elements - XHTML+SVG and the SVG containing MathML or even more layers...
16:58:04 <JibberJim> VQ - (shows Amaya demo of such a doc)
16:59:31 <bjoern> rrsagent, pointer
16:59:31 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T16-59-31
16:59:55 <MDubinko_> MDubinko_ has joined #workshop
17:00:03 <JibberJim> VQ - A single DOM tree for everything - makes editing easy and a single app handles all XML vocabs
17:01:19 <JibberJim> VQ - Wrappers such as xhtml:object/svg:foriegnObject are hidden from the user - do we need these wrappers? XHTML+MathML doesn't use them.
17:02:27 <Chris> depends on the layour semantics, xhtml and mathml are both block like reflowing, x3d and svg are not
17:03:29 <JibberJim> VQ - Editing modes - different ones need different interfaces of course - different ways to edit XML aswell - free tree structure/ source code /  constraining valid/schema docs or editing the actual application semantics.
17:05:59 <JibberJim> VQ - Specific views for specific langs - timelines for SMIL/ table of contents for HTML
17:06:33 <JibberJim> VQ - Different Style sheets for different tasks on the document
17:07:02 <JibberJim> VQ - Questions?
17:07:40 <Chris> need for W3C to define what a user agent should do  - not just markup
17:07:43 <JibberJim> We need to have a WG for User Agents - what should UA's and AT's Do?
17:07:49 <Chris> and also, what an authoring tool should do
17:07:56 <shayman> shayman has joined #workshop
17:08:23 <Hixie> i believe that was Peter Stark, Sony Ericsson
17:08:58 <JibberJim> Thanks.
17:09:12 <tvraman> tvraman has joined #workshop
17:09:19 <JibberJim> Jon F. will spur discussion:
17:09:47 <tvraman> for posterity (irc had dropped me earlier) with respect to the DBaron's access question accessibility is a function of the triple (content, user-agent, adaptive technology) -- and depending on the quality of the first two elements of this triple, you may  not need the third bit i.e. screenreaders are a band-aid that patch over broken content and badly designed user agents 
17:10:22 <JibberJim> Chris Lilley - Most of these applications aren't just working locally - how do we do security in this situation? - What are trust boundaries.
17:11:05 <JibberJim> BB - I don't have the answer, need to sign prog so we know where it came from - e.g. XML-Sig.  Standard communication library provide some control.
17:12:01 <JibberJim> MM - We already have the holes - convenience a web-services like model would be better.
17:12:29 <JibberJim> MB - Script has no place in web-apps framework.
17:12:53 <Chris> use script to build the components, but then use these components declaratively
17:13:08 <Chris> p(presumably using events for communication)
17:13:15 <JibberJim> MB - A declaritive model is more secure because we can understand the model?
17:13:54 <schepers> who would regulate a Signed script standard?
17:13:57 <Chris> "if you love something, set it free"
17:14:03 <JibberJim> Hakon Lie  - How do you save something?  do we save HTML by freezing it, or do we evolve it, or something new?
17:14:16 <JibberJim> MB - Revolution.
17:14:43 <heycam> http://angryflower.com/ifyoul.gif
17:14:45 <JibberJim> MB - If you want to save monolithic browsers, we could do it with panda logos! - I want to build apps.
17:15:22 <Chris> "save the legacy browser" with a panda logo. or perhaps a great auk - something already dead ....
17:15:22 <JibberJim> MB - really quickly.  our starting point is not saving HTML.
17:15:52 <JibberJim> BB - Revolution, we can't evolve HTML to webapps - you'd lose the essence of it.
17:17:14 <JibberJim> VQ - A revolution is impractical, we need to use the existing base, new features on top of the old.
17:17:48 <Chris> revolution does not preclude parallel deployment
17:17:49 <JibberJim> MM - We're not revolting against HTML, it's just not the tool.
17:18:41 <JibberJim> Steve Pemberton - Are web-apps and Compound docs related?
17:18:58 <Tantek> Tantek has joined #workshop
17:19:08 <Hixie> Steve Pemberton - and does it matter what the definition of compound documents are
17:19:19 <Steven> Steven
17:19:20 <Hixie> er, "is".
17:19:20 <Chris> solving B) is a necessary condition for solving a) unless there is a single WebAppML
17:19:52 <rigo> rigo has joined #workshop
17:19:52 <schepers> BB - need to distinguish between WA and CD
17:19:53 <dino> BB - I don't think they are.
17:20:23 <dino> VQ - no real relationship between files and what is displayed/edited.
17:20:46 <dino> VQ - In preparation, I was going to talk about Apps, but then I realised that it is was not necessary
17:21:01 <dino> VQ - Compound Docs needs attention and a solution.
17:21:15 <Chris> VQ: webapps require new techniques, we don't have everything we need
17:21:17 <dino> VQ - Address the two issues separately
17:21:24 <Chris> VQ: Separate issues, in summary
17:21:59 <Chris> MM: linking or inlining is irrelevant, choice of languages is the important thing
17:22:16 <Chris> MB: webappa is a special case of a compound document
17:22:30 <Chris> MB: validation and schemas for editing vs running
17:22:43 <laurent> laurent has joined #workshop
17:22:54 <Chris> MB: need to create dynamic editors that are schema aware
17:23:05 <schepers> it's only a special case if there isn't any scripting logic behind it, IMO
17:23:17 <schepers> and I think you can't get rid of script entirely
17:23:20 <laurent> laurent has left #workshop
17:23:21 <Chris> MB: distinguish rendering languages and defining languages - one barchart or 20 svg rects
17:23:32 <dino> TV. Raman - IBM
17:23:49 <JibberJim> What are we evolving from and revolting from?
17:23:54 <dino> Raman - HTML got lost in the weeds with document.write()
17:24:05 <dino> Raman - XHTML2 is rediscovering the path
17:24:06 <Chris> TVR: What are we evolving from and what are we revolting against? HTML is already lost; XHTML2 is a clean deriviation from the original concept
17:24:26 <dino> Raman - all the scripting in the 90s was an experiment on what we need for the real applications language.
17:24:30 <schepers> TVR: all of the 90s was a discovery process
17:24:31 <Tantek> time to take HTML back to its roots
17:24:31 <Chris> TVR: script experiimentation just told us what we need - now its time to codify that experience
17:24:44 <Tantek> not by adding more "gorp"(sp?) to it
17:25:01 <JibberJim> gorp?
17:25:13 <dino> I think gorp is a good name for it.
17:25:15 <schepers> feature creep
17:25:16 <Tantek> Matt May: What made HTML successful is that it satisfied the good enough technology test.
17:25:37 <Tantek> MM: There is a barrier in jumping to XHTML 1.1.
17:26:13 <Chris> moving past a barrier requires a reason to move forward. incrementally better is not a good enough reason
17:26:21 <JibberJim> MB - Aren't there 2 worlds - documents and applications.
17:26:38 <Tantek> incrementally better was good enough to move from HTML 2.0 to 3.2 to 4.0
17:26:42 <JibberJim> MB - these docs aren't applications, they don't have the key elements such as validation.
17:27:24 <JibberJim> but there's the negative steps of moving to _X_HTML - HTML 4.27 would get picked up sooner I think.
17:27:44 <Chris> using a document as a rendering simulation of an application does not make it an application
17:27:51 <Tantek> jim, right.  many folks would rather see an HTML 4.1 or 5.0 instead of an XHTML 2
17:28:30 <Chris> would it have an actual grammar you could conform to or would it still pretend to be SGML?
17:29:02 <Hixie> that's a good question
17:29:03 <JibberJim> Personally I'd rather see a set of elements which described the same infoset in XML and SGML like HTML.
17:29:07 <Tantek> Chris, customers don't seem to care
17:29:10 <Chris> its actually more work to specify an interoperable, testable HTML 5 and a real DOM 0 etc ....
17:29:27 <Chris> tantek, implementors want something that can pass CR....
17:29:30 <Yves> Yves has joined #workshop
17:31:15 <JibberJim> Gorp "granola oats raisins & peanuts" apparently... or CRAP for our more literal minded australians.
17:31:16 <danbri> danbri has joined #workshop
17:34:52 <JibberJim> Hi danbri.
17:35:22 <bjoern> rrsagent, pointer
17:35:22 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T17-35-22
17:36:04 <JibberJim> We're in coffee break btw.
17:58:12 <shayman> shayman has joined #workshop
18:00:01 <rigo> rigo has left #workshop
18:00:42 <JibberJim> We're returning for the 2nd session.
18:01:34 <JibberJim> Peter Stark from Sony Ericcson.
18:01:44 <JibberJim> PS - 4 years WML - now it's died.
18:02:06 <JibberJim> PS - XHTML + CSS and SVG in a dedicated player, simple animations, lots more next year.
18:02:09 <JibberJim> PS - SMIL in MMS.
18:02:34 <JibberJim> PS - SMIL+SVG rarely used together today.
18:02:54 <JibberJim> PS - Camera phones and graphics based UI's raise the bar for mobile web apps
18:03:27 <JibberJim> PS - Imaging+slideshows XHTML+SMIL, graphics based websites rather than text, so SVG+XHTML+CSS
18:03:56 <JibberJim> PS - new UI movement and depth inside the UI using SVG+SMIL. user expectation is higher, need better web pages than what we have today,.
18:04:06 <dino> s/Ericcson/Ericsson/ :)
18:04:07 <Chris> high user expectations for the visual aspect - needs more SVG, more SMIL
18:04:25 <Chris> needs a language profile of XHTML, SVG and SMIL, to ensure interoperability
18:04:42 <JibberJim> PS - How do we combine the languages? HTML+css and HTML+script are well defined, SVG+SMIL not.
18:04:57 <Chris> needs a language profile of XHTML Basic, SVG Tiny  and SMIL Basic, to ensure interoperability
18:04:58 <JibberJim> PS - profiles allow us to create better authoring tools.
18:05:21 <dino> PS - Authoring tools are really needed to create Mobile Web Apps
18:05:22 <JibberJim> PS - we have nothing today, these profiles should help.
18:05:33 <Chris> authoring tools can then output to a standard profile instead of a specific phone
18:05:40 <JibberJim> PS - that's it!
18:06:30 <JibberJim> Dan Zucker from access - You propose a mobile profile - good idea for interop, but isn't it a moving target? phones always get new features, how to you do the trade off?
18:07:07 <JibberJim> Profiles allow vendors to demand or know the areas.
18:07:48 <JibberJim> TV Raman - we've got to be careful about profiles, are we obsoleteing are content by authoring to out of date profiles - need to make the content future proof.
18:07:57 <JibberJim> PS - at the moment there's no profiles, we need some.
18:09:10 <JibberJim> ChrisLilley - just what tags isn't enough - you also need more about how events flow, and more conformance req's on a UA - otherwise AT's won't be able to make good docs.
18:10:13 <Chris> (Its not a specific device, though - eventually the desktop will catch up with the mobile world!
18:10:21 <JibberJim> (someone) you're proposing specific solutions for specific advices - what you really want is a general solution to this problem?
18:10:21 <heycam> i agree with the sun guy, there needs to be a way to specify generally how different namespaced elements can work together
18:10:47 <Hixie> that was Daniel Austin from Sun
18:10:52 <JibberJim> cheers
18:11:11 <Chris> CL: AU specs for that profile need to go through a CR phase and be demonstrably interoperable and useful for the content authoring community
18:11:24 <Chris> s/AU/UA
18:11:41 <Hixie> Astronomical Unit specs?
18:11:56 <JibberJim> Handheld devices go faster than specifications, why do we "dumb down" specs rather than aim for future phones?
18:12:04 <Hixie> Chris: so _that_'s why SVG is such a big spec. ;-)
18:12:29 <JibberJim> Nah,  I think Dino just likes typing...
18:12:46 <Hixie> hah
18:13:16 <schepers> the "dumb down" question was from Glen Gersten of Ideaburst
18:13:30 <JibberJim> CL again - minimum requirements... the desktop is catching up the phones, we'll get there soon.
18:13:47 <JibberJim> TV. Raman
18:14:20 <JibberJim> TVR: Compound docs and webapps are interlinked.
18:15:46 <JibberJim> TVR: Webapps are deployed across network, aggregrate net. services, client and server are independant, back to the basics of the web.
18:16:39 <JibberJim> TVR: Pre-requisites are Factor ourt content/style/presentation, seperate memory model from UI logic.
18:17:30 <JibberJim> TVR: Bolting different heads onto webapps - webapps and web-services are similar.
18:17:59 <JibberJim> TVR: web services are xml models for machine to machine, webapps is machine to user but otherise similar.
18:18:20 <JibberJim> TVR: How do we change a pizza store into a webapplication?
18:18:56 <JibberJim> TVR: Building on what we have - web-applications as compound docs.
18:19:52 <JibberJim> TVR: W3 Arch. is interopable at each point - we've settled on angle brackets - XML is everywhere, your compound doc is versatile deployment.
18:20:15 <JibberJim> TVR: The key bit is eventing.
18:20:51 <JibberJim> TVR: building blocks - Module/namespace/protocol/http
18:21:04 <JibberJim> TVR: container/xhtml/runtime/xml dom
18:21:15 <JibberJim> TVR: content XHTML/style/css
18:21:25 <JibberJim> TVR: metadata/RDF/timing/smil
18:21:38 <JibberJim> TVR: Vectors/SVG/Voice/VoiceXML
18:21:47 <JibberJim> TVR: XSchema/XPath
18:21:54 <JibberJim> TVR: XSL/Xquery
18:22:03 <JibberJim> TVR: Xforms and XML Events
18:22:47 <JibberJim> TVR: These are the building blocks but thinks break at the boundary - the A element has interaction semantics - the B element has the semantics styled as bold, we need to put things together.
18:23:10 <JibberJim> TVR: If we solve these issues, the web is ready to take off again.
18:25:23 <JibberJim> Hermando(?) form Coolpix - Declaritive compound docs has had me running into pragramatic levels - how do I interface my imperative languages to the declaritive one - no easy way to interface the code to the declaritive info - declaritive programming is taking too long to develop.
18:25:32 <heycam> strong typing!
18:26:10 <JibberJim> TVR: The client model hasn't evolved, we've still just got HTML and JS and that's hard to debug.
18:26:25 <JibberJim> TVR: A richer client model becomes easier to debug.
18:27:02 <JibberJim> Daniel Austin - If we solve Compound Docs problem will we solve web-apps?
18:27:29 <JibberJim> TVR: Compound Docs won't let us implement doom, but they'll give us a lot.
18:27:51 <JibberJim> dino: 5120bytes of javascript for doom...
18:28:08 <JibberJim> JonF from Adobe:
18:28:49 <JibberJim> JF: lots of Doc formats from Adobe - PDF is "Intelligent documents" doing multiple doc formats with RDF/ES/XML etc.
18:29:11 <shayman> shayman has joined #workshop
18:29:49 <JibberJim> JF:Lots of SVG experience, SVG player supports SMIL and XHTML, XBL, ES +java bindings, comms methods - sockets etc.
18:30:32 <JibberJim> JF: Should:  Deliberate process - short cuts don't work, have a low ambition initially.
18:30:52 <JibberJim> JF: Codify and integrate what exists today
18:31:02 <JibberJim> (freudian slip on "everything exists in SVG")
18:31:25 <JibberJim> JF: XHTML and SVG 1.2 are the key lanaguages
18:31:46 <JibberJim> JF: Focus on Mobile, standards are winning there, already using XHTMLb and SVGt
18:32:13 <JibberJim> JF: webapps SVG 1.2+xbl and SVG1.2+window interface
18:32:17 <dino> JF: In Mobile, vendors are following the standards process and *implementing* the standards
18:32:47 <JibberJim> JF: Compound docs - start simple, use seperate files, then compound the docs, don't invent features that substitute for packaging.
18:33:37 <JibberJim> JF: key point - deliberate process, codify and integrate, focus on mobile.
18:34:11 <JibberJim> Lee Clark from Xerox - You didn't mention XForms, why?
18:34:50 <Chris> from the Adobe paper "For web applications, the W3C should leverage its existing standards (e.g., DOM, XForms, XHTML, SVG) and all of
18:34:50 <Chris> the applications-related features that are in SVG 1.2, particularly RCC/XBL, the features on the “Window” interface,
18:34:51 <Chris> and the SVG Tiny uDOM that has been developed in conjunction with J2ME and JCP/JSR226."
18:34:58 <JibberJim> JF: It's a tough question for us to address.
18:35:41 <JibberJim> _Steven_ Pemberton: will you be merging the "Adobe Viewer" and the SVG viewer?
18:36:05 <Hixie> footnote for before -- the 5k game mentioned earlier is at http://www.innofinity.com/5k/2002/
18:36:07 <JibberJim> JF: I can't comment - various support to move towards standards.
18:36:26 <JibberJim> Vincent Hardy from Sun:
18:37:13 <dino> VH: Sun has a lot of experience in XML and applications
18:37:21 <JibberJim> VH: Docs and apps need XML
18:37:48 <JibberJim> VH: the W3 standards are in seperate silos, everything focussed on the own WG rather than proper interop.
18:38:25 <dino> VH: The W3C specs are great by themselves, but people want a bit of everything.
18:38:42 <dino> VH: eg. SVG has great features, eg filters and markers, but no layout from CSS.
18:38:43 <JibberJim> VH: SVG has great stuff, filters and markup - but no layout e.g. CSS box model.
18:39:07 <dino> VH: eg. the only image format you can rely on in HTML is raster. You still can't use SVG.
18:39:22 <dino> VH: Problem: we want to use the features from different specs.
18:39:22 <JibberJim> VH: Isolated silos of XML standards, we get redundant different solutions in different specs
18:39:27 <Tantek> [diagram shows silos: (SVG) (XHTML) (SMIL) (XForms) (...) ]
18:39:31 <Dan> Dan has joined #workshop
18:39:55 <Tantek> How are XHTML and XForms separate silos?
18:40:21 <JibberJim> Artistic license?
18:40:53 <dino> VH: Focus on what application developers want.
18:41:01 <dino> VH: Combining markup delivers value.
18:41:08 <JibberJim> We want script!#
18:41:47 <dino> VH: Lots of good stuff at W3C [shows table of many formats]
18:41:55 <JibberJim> VH: combining existing features:  document and page layout, resolution independance, multi-media integration, animation, ui components, extensibility.
18:42:06 <JibberJim> VH: and the various W3 specs and drafts to give those.
18:42:20 <mdubinko> acronym check: what's RCC again?
18:42:23 <dino> [specs mentioned: SMIL CSS, XSL, SVG, XForms, RCC]
18:42:27 <dino> RCC is now XBL
18:42:36 <Hixie> stands for Rendering Custom Content
18:43:00 <schepers> XBL == XML Binding Language
18:43:49 <dino> VH: My experience is that developing a spec is really hard.
18:43:57 <JibberJim> VH: Challenges, semantic and architecture - it's hard to do a good job, testing etc. combining formats makes it even harder.
18:43:58 <dino> VH: Combining them may be exponentially harder
18:45:34 <dino> VH: limit the integration points. manage complexity
18:46:18 <JibberJim> VH: Static or dynamic behaviour? how do we limit?
18:46:34 <JibberJim> VH: generic or specific API's - specific API's were useful in SVG.
18:46:56 <JibberJim> VH: XML is complex!
18:47:14 <JibberJim> VH: minimise and simplify the integration points so we get something implementable.
18:47:32 <JibberJim> CL - XML processing pipeline submission from Sun.
18:47:41 <JibberJim> CL can you comment?
18:48:41 <JibberJim> Mark Birkbeck - These are the problems I agree, I think that's why we need to go up to a meta level, it won't work just tweaking this level.  The silos are just too big.
18:49:08 <JibberJim> MB - 3 have how to load a document, 2 years to produce a spec. we've got to break these things down.
18:49:25 <JibberJim> VH couldn't comment on CL's comment btw.
18:49:53 <JibberJim> VH: if we reduce and simplify we get more interop. implementations.
18:50:41 <JibberJim> VH: SE have processors for all the systems, integrate is important.
18:51:55 <schepers> Dean Jackson asked if any other vendors had points to make
18:52:44 <Tantek> Suresh asked why it takes so long to get the specs supported.
18:52:47 <schepers> Suresh  Chitturi (nokia) - why are specs taking so long, why can't we do things quicker?
18:53:19 <Tantek> Suresh - e.g. SVG (v?) 2003 Jan over a year ago.
18:53:27 <JibberJim> VH: lots of testing.
18:53:41 <JibberJim> well test-cases.
18:54:44 <JibberJim> TVR: the delay between creation and implementation - haste makes waste - WG get pushed down shortcuts, but the constraints become irrelevant - they'll always take time.  Modular specs is the lesson.
18:55:07 <JibberJim> TVR: You could write a web browser in 2 pages of perl
18:55:16 <JibberJim> I thought you could write anything in 2 pages of perl?
18:55:41 <JibberJim> TVR: the new specs are more modular, an XML browser should be much easier to write than a 1999 HTML UA.
18:56:01 <bert_lap> Perl: depends on the line length your editor supports :-)
18:56:16 <JibberJim> JF: W3 needs to take more of a lead.
18:57:23 <JibberJim> Hakon Lie: Namespaces - lots of specs to be combined, - namespaces have problems, what happens when meet unknown namespaces?
18:57:25 <Chris> HL: Namespaces have problems .....unknown namespaces for example
18:57:44 <JibberJim> HL: Are namespaces the solution?
18:58:38 <Hixie> HL also mentioned that Micah's paper mentions that most of the questions he receives about XForms come out of confusion about namespaces
18:58:40 <Chris> VH: namespaces is a technique to allow non-clashing names.Its not a complete solution. Combinations can be made for many different reasons, eg as metadata
18:58:42 <JibberJim> VH: namespaces are technique which solve a syntactic problem, but not the intent of the mixed markup, different models are the problem.
18:58:46 <Chris> need to know th erendering intent
18:59:31 <Chris> putting all in one namespace does not solve the semantic issue; its a syntactic technique only
19:00:13 <JibberJim> Tantek Celik: A single namespace for doc. formats combine SVG/HTML to remove the silos between the specs.
19:00:29 <Chris> JF: Namespaces are already out there, can't turn back the clock
19:00:31 <JibberJim> JF: namespace pandoras box is open... we can't get it back, we just need to make them work.
19:00:42 <Chris> any robust system has namespace scoping
19:00:49 <Chris> not all global variables
19:01:43 <JibberJim> TVR: Namespaces and HTTP are similar, so basic, just take and move on, it solves the syntax problem.
19:02:28 <Tantek> Namespaces cause more problems than they solve, that's the problem.
19:02:36 <JibberJim> Charles: Content developers need to be involved earlier in the process.
19:02:43 <Chris> Charles ying, Openwave - involve content developers in spec design
19:02:54 <Hixie> tvraman: if we didn't use namespaces we would have svg-a instead of svg:a
19:03:18 <Hixie> (of course it's not really svg-a vs svg:a, but svg-a vs svg:a xmlns:svg="..." where "svg" can have any value...)
19:03:29 <mdubinko> +1 to Tantek, but the *concept* of namespaces is OK; the way it shows up in the XML causes more problems than it solves
19:03:46 <JibberJim> Steven Pemberton - Join the Working Groups if you want input.
19:04:16 <Tantek> micah, the concept of namespaces *can* be ok, in *some* scenarios.
19:04:31 <Tantek> there was *no need* for namespaces for *W3C* *document formats*
19:04:32 <Chris> Peter Stark, Sony Erricsson - authoring tool developers should be involved too
19:04:39 <JibberJim> PS: You cannot create a good SVG tiny document.
19:05:39 <JibberJim> Scott : There are other standards bodies working on integrating compound docs, you need to pick it up and do it sooner rather than later.
19:05:45 <Chris> Scott Hayman, Research in Motion
19:05:56 <Chris> Marc Verstaen, Beatware
19:06:28 <JibberJim> (who has an SVG tiny authoring tool...)
19:06:29 <Tantek> namespaces as a syntax, as a technology, are directly the cause of and responsible for the various silos
19:06:56 <Tantek> namespaces cause tribalisation, and encourage redundant solutions to the same problem, rather than reuse (the <a> tag example)
19:07:00 <JibberJim> but how implementable would the combined spec have been? can you combine the different rendering models?
19:07:18 <Tantek> the point is as Jon said, "take your time, and don't rush it"
19:07:19 <Hixie> maybe the rendering models wouldn't have been so different
19:07:31 <Hixie> and that this difference is part of the problem
19:07:39 <MarkS> MarkS has joined #workshop
19:07:40 <schepers> Marc Verstaen: the W3C needs to give authoring tools more visibility
19:07:41 <Tantek> different namespaces at W3C enable the groups to NOT talk to each other
19:07:57 <Tantek> thus you end up with duplicate tags, incompatible rendering models etc.
19:08:00 <JibberJim> Yes, but X3D/SVG/HTML+CSS are quite distinct rendering models.
19:08:15 <Tantek> rather than reused tags, modular rendering models etc.
19:08:53 <JibberJim> TVR: We need to escape the idea of innovating within the browser sandbox.
19:09:01 <AntoineQuint> AntoineQuint has joined #workshop
19:09:05 <CY> for the minutes: proactively involve content developers earlier on in the specification process.
19:09:13 <Chris> TVR: boxed ourselves into a sandbox, can't work with one hand behind our backs
19:09:36 <JibberJim> Steven Pemberton - 5years to critical mass is acceptable, it's a reasonable timeframe.
19:10:17 <JibberJim> VH - the mobile world provides a different enviroment, with much shorter cycles, people upgrade quicker.
19:10:24 <Chris> VH: Cycles in mobile a lot shorter than desktop, so more adoption of W3C specs
19:10:51 <Chris>  - and also they don't have the legacy to slow them down
19:11:23 <Chris> PS: still toook time t transition from legacy WML to XHTML Basic
19:11:56 <JibberJim> dino - Vodaphone update their cycles every 6 months.
19:12:11 <Chris> DJ: Vodaphone as an example has a 6 month release cycle, so easier to deploy new content and new implementations
19:12:21 <JibberJim> Bert Bos - Profiles?  should we have profiles for desktop?
19:12:29 <Chris> Bert Bos, W3C: Profiles of user agents, not just markup
19:12:46 <Chris> BB: Why is this being done on mobile and not on the desktop?
19:13:10 <schepers> because IE drives adoption
19:13:41 <JibberJim> no, because desktop UA's are user customisable, whereas phone UI's are not.
19:13:52 <Chris> JF: Market dynamics are different, and they need this to work to build services on top
19:14:12 <Chris> JF: Desktop has proprietary rulership, so it works less well
19:14:53 <Chris> VH: Profiles for larger feature sets are harder to do
19:15:23 <Chris> CL: but having at minimum the mobile profiles available on the desktop woul;d be a big help
19:15:25 <JibberJim> PS: docomo/vodaphone etc. drive standardisation.
19:15:39 <Chris> David Baron, Mozilla Foundation:
19:16:10 <JibberJim> DB: Web is neat 'cos of universal access from any machine
19:17:18 <Hixie> dbaron: What's the point of device-specific profiles?
19:17:32 <Tantek> dbaron: or are they for some sort of proprietary network?
19:17:56 <JibberJim> VH: content authors make decisions based on who can view, so it increases penetration
19:19:31 <Chris> DanielZucker, Access Co.
19:20:28 <JibberJim> DZ should lead mobile profiles - lots of other standards bodies.
19:20:43 <Chris> Mark Birbeck, X-Port
19:20:43 <Tantek> Daniel: there are 3 mobile standards groups.  3GPP, 3GPP2, OMA
19:20:53 <Chris> Mark Birbeck, X-Port.net sorry
19:20:56 <Tantek> Daniel: point of mobile profile is to avoid three different profiles
19:23:04 <Chris> Daniel Austin, Sun Microsystems
19:25:09 <shayman> shayman has joined #workshop
19:25:22 <JibberJim> mobile phones with 6 month dev cycles are scary for security issues, with our (microsofts) experience of rushing to market led to lots of security issues.
19:25:40 <JibberJim> (I didn't catch his name)
19:25:42 <CY> Alex Hoffman was the speaker
19:25:48 <JibberJim> Cheers!
19:25:53 <schepers> Hopman, I think
19:26:00 <CY> ah, likely
19:26:02 <Tantek> Alex Hopmann, Microsoft
19:26:18 <Chris> Mobile Division?
19:26:51 <JibberJim> MB - if the vendors don't do it in the mobile world, the content providers (vodaphone live etc) will do it instead.
19:27:25 <CY> Alex Hopmann is in the Avalon team, I believe.
19:27:41 <Chris> JF: turnover is on devices, not on the content
19:28:09 <Chris> TVR: what does not change - finger size, (battery life) user experience needs
19:30:28 <JibberJim> We're forgetting market factors, concentrating on how we can get authoring/viewers etc. all together at market at the same time, there's no point having conformant viewers if we don't have viewers driving.
19:30:34 <CY> (Glen Gersten)
19:30:48 <Chris> Scott Hayman, Research in Motion
19:30:49 <JibberJim> thanks  - I'm very bad at catching names)
19:31:44 <JibberJim> On a desktop you can implement anything, on the mobile you get a tight, what you can implement specification, which is a reason why profiling doesn't work on the desktop.
19:31:50 <JibberJim> Dino - lunch.
19:31:51 <Chris> Profiling works on mobile because fixed code size enforces discipline on cutting things
20:08:41 <MarkS> MarkS has joined #workshop
20:29:06 <dino> dino has joined #workshop
20:41:51 <sac> sac has joined #workshop
20:51:10 <dbaron> dbaron has joined #workshop
20:51:20 <klotz> klotz has joined #workshop
20:51:21 <MarkS> MarkS has joined #workshop
20:51:48 <sac> sac has joined #workshop
20:52:08 <Dave> Dave has joined #workshop
20:54:27 <Hixie> Hixie has joined #workshop
21:04:57 <junior> junior has joined #workshop
21:05:16 <Steven_> Steven_ has joined #workshop
21:05:47 <dino> Hakon Lie, Ian Hickson - Opera
21:05:52 <dino> David Baron - Mozilla
21:06:17 <dino> HL: Join submission since joint interests. We've both been developing browsers for a while.
21:06:32 <dino> HL: [shows Lemmings done in Javascript, HTML, CSS and DOM]
21:07:04 <dino> HL: Scary code - we don't want to recommend this. But we think the pieces are in place.
21:07:10 <tvraman> tvraman has joined #workshop
21:07:13 <dino> HL: Make it easier for the developers.
21:07:18 <dino> -> Ian Hickson
21:07:40 <dino> IH: My favourite subject is backwards compatibility.
21:07:50 <tvraman> and how would this CSS powered game work with accessibility, device independence etc? Does backward compatibility imply maintaining inaccessibility?
21:07:52 <dino> IH: Lots of people have talked about apps with SVG and XForms in XML
21:08:06 <dino> IH: Not the best idea in the short term.
21:08:09 <Steven> Steven has changed the topic to: Workshop on Web Applications and Compound Documents
21:08:27 <dino> IH: Accessibility is in trouble now. We need a solution right away.
21:08:37 <dino> IH: Deployment in today's browsers.
21:08:46 <dino> IH: Apps already exist - Amazon.com and ebay
21:08:57 <dino> IH: Wide range from interactivity to hyperlinking
21:09:11 <dino> IH: Graceful degradation is important.
21:09:33 <shayman> shayman has joined #workshop
21:10:07 <dino> IH: Hakon mentioned IE. It has a huge share of the market. Authors target it.
21:10:18 <dino> IH: [mentions CSS and PNG support in IE]
21:10:19 <JibberJim> JibberJim has joined #workshop
21:10:37 <tvraman> does anyone remember the kluges we added in hTML 4 to "hide new content from downstream/old browsers"? we got cdata sections wrapped in sgml comments wrapped in c++ comments that held javascript:-)
21:10:48 <JibberJim> Yeah, but that was a cargo cult.
21:10:57 <dino> IH: Flash is used a lot, because IE ships with a Flash plugin.
21:11:09 <JibberJim> RRSAgent, pointer
21:11:09 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T21-11-09
21:11:23 <dino> IH: [mentions IE7 project to do CSS2 via behaviours]
21:11:36 <dino> IH: It is possible to write new technologies in IE currently.
21:11:55 <Dan> Dan has joined #workshop
21:12:00 <dino> IH: Solution based on HTML is better than one that isn't/
21:12:05 <dino> -> David Baron
21:12:21 <dino> DB: Web is a system for universal access to information
21:12:35 <dino> DB: Want specifications such that devices can work with all content.
21:12:56 <dino> DB: It isn't easy. Interoperability is hard. Need to limit the number of document formats you have.
21:13:03 <MDubinko> MDubinko has joined #workshop
21:13:03 <Hixie> Hixie has joined #workshop
21:13:48 <bert_lap> bert_lap has joined #workshop
21:13:57 <dino> DB: One solution is to write profiles. I think this is the wrong solution. Signs of a problem that there are too many documents, or they are too difficult.
21:14:11 <dino> DB: Device-specific profiling should be avoided.
21:14:26 <dino> DB: Profiling on presentation side is probably acceptable.
21:14:46 <dino> HL: We have more stuff in our position paper.
21:14:55 <Chris> Chris has joined #workshop
21:14:57 <heycam> heycam has joined #workshop
21:15:00 <dino> HL: Is opera still the rebel web browser?
21:15:10 <Chris> HL: no
21:15:11 <dino> HL: Probably not in this case. We are on the evolution side.
21:15:31 <schepers> schepers has joined #workshop
21:17:00 <JibberJim> CL Question: There was a logical errror - People use Flash 'cos it ships with the O/S - but 50% of people who use IE6 upgraded to it, are downloads really a problem?
21:17:13 <JibberJim> CL: When Longhorn ships it's a problem...
21:18:21 <JibberJim> IH - not seen IE6 download stats, IE7 is just included script.
21:18:55 <Chris> CL: any attempt to build last years browser is doomed to failure
21:19:01 <JibberJim> Why was CC/PP not successful ?
21:19:04 <klotz> Who?
21:19:07 <Steven> Steven has left #workshop
21:19:13 <JibberJim> you tell me!
21:19:19 <JibberJim> :-)
21:19:37 <klotz> http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/2004jun01.html
21:20:24 <MDubinko> klotz++ # nice
21:20:38 <JibberJim> klotz++
21:20:49 <Chris> Agree that device specific profiles should be avoided. The mobile web stuff is not actually device specific, they just want a technology platform that actually works
21:21:09 <JibberJim> And are solved by SVG+script...
21:21:09 <jrandall> jrandall has joined #workshop
21:22:08 <Hixie> Hixie has joined #workshop
21:22:21 <JibberJim> Alex Hoffman (Hopman?) from MS.
21:22:42 <JibberJim> MS has been deploying rich client apps since IE4.
21:22:45 <schepers> Hopmann
21:22:52 <dino> Hopmann
21:23:29 <dino> AH: Security is important. Interoperability is important.
21:23:33 <JibberJim> MS has been deploying rich client apps since IE4.
21:23:51 <dino> Previously AH: We've been deploying web apps since ie4 - Outlook Web veiw
21:24:03 <JibberJim> AH: When you deploy of net, you can use interop of schemas, http, network etc.
21:24:14 <dino> AH: Customers tell us they want to deploy over network, quick update.
21:24:32 <dino> AH: interesting to look at differences between docs and apps
21:24:44 <JibberJim> AH: evolve apps quickly, the content and document are deployed differently although there's a continum, content tends to be stuff that's interesting in the future
21:24:48 <dino> AH: Content is useful to me 5/10 years from now.
21:24:55 <JibberJim> AH: content is still relevant in 10 years.
21:24:58 <Steven> Steven has joined #workshop
21:25:20 <JibberJim> AH: Interop allows future proofing - apps have a different lifespan, they're constantly evolving.
21:25:27 <Tantek> Tantek has joined #workshop
21:25:55 <JibberJim> AH: webapps are popular because we can deploy the new version instantly.
21:26:13 <JibberJim> AH: capabilities change, new platforms are ok.
21:26:21 <JibberJim> AH: A little about Longhorn...
21:26:42 <JibberJim> AH:Presentation pillar, comms pillar, data pillar.
21:26:50 <JibberJim> AH: Avalon is the pres. pillar.
21:27:21 <Chris> three pillars like the TAG tripod ....
21:27:30 <JibberJim> AH: Indigo is the web-services interop focussed.
21:28:25 <JibberJim> AH: XAML we're combining imperative and declaritive nature, so that the UI guys and tools can work on it.
21:29:08 <robin> robin has joined #workshop
21:29:17 <JibberJim> AH: Button tag in XAML - there's a button tag, simply because there's a button class, if we have a donkey class, there'd be a donkey tag too.
21:29:40 <JibberJim> AH: 3D graphics support and more, not just regular old buttons and forms etc.
21:30:42 <JibberJim> AH: It can be run in the browser, or could be run in other Chrome - it's not an primary decision it can go anywhere.
21:30:52 <Chris> IE team is working primarily on security
21:30:53 <JibberJim> AH: IE team has been focussed on security, but they are workign!
21:31:12 <Chris> not "whizz-bang features" ....
21:31:54 <JibberJim> AH: Developers want imperative code because you can do fun things.
21:32:37 <JibberJim> AH: They're security problem is a couple of orders worse.
21:32:47 <JibberJim> AH: The system is more fragile.
21:33:04 <JibberJim> AH: people should stayed focused on declaritive formats.
21:33:39 <tvraman> All the points being made here are a *very* good sell for XForms though the x word wasn't mentioned 
21:33:42 <JibberJim> AH: People should tie everything together with interopable web services.
21:34:20 <JibberJim> Patrick Shmidt(?) - IE sustaining effort and avalon - what is going to happen to something browser like in the longhorn space?
21:34:27 <Chris> Schmidt
21:35:23 <Chris> AH: IE is an activeX frame, things can run inside it eg trident html module
21:35:41 <Chris> AH: no plans to replace existing Trident module for legacy web
21:35:57 <Chris> bug compatible on top 1000 web sites
21:36:10 <JibberJim> AH: we just look at new renderers for new technology.
21:36:26 <JibberJim> PS - What will happen with SVG or XHTML inside Avalon
21:36:36 <Chris> AH: we have no announcements in terms of XHTML or SVG o Avalon, third parties can bui;d them ...
21:36:40 <MDubinko> Armando Peña
21:37:20 <JibberJim> AP: Declaritive/imperative what abouts at the CLR/IM level for these xaml classes?
21:37:39 <MDubinko> how deep do the semantics go?
21:37:49 <Chris> AP: custom markup lus a class that implements it - doing this already in java - how does this reflect at the CLR level so things stiill know it s a button. Keep the semantics of the language
21:39:43 <JibberJim> Hakon Lie: XAML when are you going to submit to w3?
21:40:38 <JibberJim> AH: No plans it's a mark-up system for windows, not for the web.
21:40:46 <schepers> well, we already have SVG, don't we?
21:41:50 <JibberJim> Owen Taylot: RedHat
21:41:55 <JibberJim> Taylor
21:42:05 <JibberJim> OT: The open source desktop - a diverse environment
21:42:48 <JibberJim> OT: linux/bsd/solaris - gnome/kde - GTK++,Qt, Java, etc.
21:43:27 <JibberJim> OT: Developer convergence - now developers using the same technologies on the desktop from the web space.
21:43:43 <JibberJim> OT: Is the desktop app dead? more hybrid apps.
21:44:12 <JibberJim> OT: User convergence - they want seamless integration and identical look and feel.
21:44:40 <JibberJim> OT: standardise infrastructure not entire toolkits.
21:46:03 <JibberJim> OT: download application+toolkit from the web toolkit needs to be freewheeling and don't have a huge stack of standards too much to implement, too much to learn
21:47:40 <JibberJim> OT: seperate application from toolkit - or seperate UI from content can lead to anything goes UI - best is to seperate it down to Content/UI Structure/Appearance
21:48:10 <JibberJim> OT: not content from UI, but structured UI from appearance UI.
21:49:05 <JibberJim> OT: how do we standardize a theme so it looks native on every platform - need to create central hub.
21:49:55 <JibberJim> OT: not really sure what it's like.
21:50:28 <JibberJim> OT: Steven Pemberton - Xforms is the 3 seperation.
21:50:45 <Hixie> so's HTML, in fact
21:50:45 <JibberJim> Why do webapps need a native look feel?
21:51:06 <JibberJim> in an ideal world Hixie, it's too commonly abused I think.
21:51:29 <Hixie> so would xforms if it was as popular :-)
21:51:37 <JibberJim> OT: Why not have a Unified look and feel for a standard web-app.
21:51:47 <JibberJim> Audience: Why not have a Unified look and feel for a standard web-app?
21:51:55 <Chris> like Java did, and then moved away from because everyone hated it?
21:52:08 <JibberJim> OT: No, people and users want their distinct look.
21:52:19 <robin> HTML has UI structure? Beyond the toy level? I was unaware.
21:52:51 <Hixie> robin: sure. <input type="text"> means "an input control that allows text input".  <input type="file"> means "an input control that allows for file upload".
21:53:02 <JibberJim> Bert Bos: Command line and phone applications need to be distinct from a UI structure.
21:53:11 <schepers> if the theme is identical to the desktop app, it may confuse people as to the danger of allowing permissions to the Web App
21:53:13 <tvraman> this time it's my turn to say XForms does that:-)
21:53:13 <Hixie> <fieldset> means "this is a group of related controls"
21:53:14 <Hixie> etc
21:53:28 <Hixie> tvraman: but xforms isn't backwards compatible
21:53:35 <JibberJim> Doesn't XForms do everything? the spec's big enough :-)
21:53:37 <robin> Hixie: how do I make ranges, colour pickers, loops...?
21:53:56 <Hixie> robin: use my web forms 2 proposal. How do I do literal XML editing in XForms?
21:54:04 <tvraman> Bert's question was how do I design the app so theming becomes broader than just different color schemes -- make app usable from different interfaces.
21:54:29 <robin> literal as in hacking the tags?
21:54:31 <tvraman> There are implementations that let you deliver an XForms app via IM using interactive chat --- even better than telnet -- what's more it's even fashionable
21:54:31 <Hixie> yes
21:54:31 <JibberJim> Mark Birbeck - Theming is a problem a GUI and voice system are way too different to standardise.
21:55:02 <Hixie> robin: or how do you do a map control in xforms
21:55:02 <robin> if you want to edit text, put it in a text field :)
21:55:20 <Hixie> robin: or how do you do <anything xforms doesn't do yet> in xforms
21:55:21 <robin> what's a map control? pan/zoom?
21:55:22 <JibberJim> MB - we can start building abstract controls from basic XForms components.
21:55:27 <Hixie> robin: for example
21:55:37 <robin> with a set of ranges
21:55:43 <tvraman> I'll speak about the XForms 1.0 -- not any bizarre extension to html:-) but that said you use a well-formed XML document -- including xhtml -- as an instance to which you bind an XForms UI. But then, Ian that wont work for you since you've confessed to not liking indirection
21:55:49 <robin> controlling the viewport of an SVG document
21:55:58 <Hixie> tvraman: sure, html4 forms are very limited compared to xforms 1.0
21:56:27 <Hixie> tvraman: my point is that you can make html be as powerful as xforms without breaking backwards compatibility
21:56:32 <tvraman> Glad to hear you acknowledge that Ian -- now you can continue saying it's power that no one needs:-)
21:56:38 <JibberJim> MB - we can't make 20 widgets that everyone will ever need, more lots more than them.
21:56:52 <Hixie> tvraman: no, i think it's power we need. we just need backwards compatibility more.
21:57:13 <Hixie> tvraman: xforms would be great if it was just an extension to html instead of a whole new incompatible language
21:57:49 <schepers> Rich Schwarzfegger
21:58:02 <JibberJim> RS: we need device capabilities in the standard, we need to know what a system can do.
21:58:03 <tvraman> define backward compatibility? Sadly though a Linux lover I have to say that the MS guy hit it on the head --- keep legacy html support in the old browser, but dont cripple forward evolution --- independent of having done the xforms work, if I walked into this room cold and listened to the MS pitch vs what yu and howcome said I confess I have to agree with the xaml view. Only saving grace is that XForms is here today--
21:58:14 <JibberJim> Sara Allen - Laszlo Systems
21:58:35 <robin> besides, backwards compatibility with which implementation?
21:58:36 <JibberJim> SA The future of the web is not a re-implementation of windwos.
21:58:46 <tvraman> so ian define extension --- just one more kluge to a stack of kluges? we stopped that in 1998 in case you hadn't noticed:-)
21:58:58 <Tantek> tv, namespaces are a kluge
21:59:31 <JibberJim> SA: Consumers envision a very different experience - the Earthlink personal start page.
21:59:31 <Hixie> tvraman: backwards compatibility meaning (a) it can gracefully degrade in existing browsers; (b) it can be implemented in IE6 without binary plugins; (c) it reuses existing authors' knowledge, and (d) it can be added to existing documents without requiring the rest of those documents to change.
21:59:43 <JibberJim> [shows awful unusable animated system]
22:00:02 <JibberJim> SA: Tremendous info in small space - very different from UI, more like TV!
22:00:41 <robin> implemented in IE6 without binary plugins? So that we're sure that it's obsolete when IE6 is replaced?
22:00:47 <JibberJim> SA: Animation is not a gratuitous effect, it's for education.
22:00:57 <JibberJim> [looks unusable to me!]
22:01:02 <Hixie> robin: no, non-IE browsers wouldof course implement it natively
22:01:07 <heycam> microsoft bob!
22:01:11 <tvraman> Ian -- see my comment on the IRC channel earlier about the slippery slope your suggestions led us down in the HTML 4 time frame cdata sections wrapping javascript comments inside xml comments --- it's not tractable any more. Anyway marketplace will decide 
22:01:23 <JibberJim> SA: Strange message in a bottle UI, can customise it.
22:01:33 <JibberJim> SA: "The cinematic user experience"
22:01:49 <robin> Hixie: yeah, but until they have larger market share, that's largely irrelevant
22:02:11 <robin> and the chance of them acquiring said marketshare while proposing nothing better than IE is null
22:02:14 <Hixie> robin: until they (whatever is supposed to replace IE) has a larger market share, _any_ solution is irrelevant
22:02:23 <JibberJim> SA: Calendar app showing re-arranging views on the similar view using lots of animation to help users.
22:02:48 <Hixie> robin: Mozilla, Opera and Safari all already support significantly better standards and have significantly better UI than any released version of IE.
22:02:51 <JibberJim> SA: These UI's are different to windows UI's - these basic UI's are used - buttons tabs, checkboxes etc.
22:03:15 <Hixie> robin: it hasn't helped much
22:03:19 <robin> Hixie: significantly in incremental terms, they offer close to nothing that would want to make one switch
22:03:24 <robin> save ideology
22:03:25 <JibberJim> Hixie, UI's are a personal thing, we can't say better.
22:03:30 <Tantek> SA: these UI components are completely keyboard navigable
22:03:33 <Chris> the animation transitions are good because they show the user how the previous view became the new one
22:03:41 <Tantek> SA: developers can write their own UI componenets
22:03:56 <Hixie> robin: to the user, none of the proposals given so far today are better than what IE does
22:04:06 <JibberJim> SA: Another Demo, using the web to send MMS's to cellphones.
22:04:25 <tvraman> can someone tell me what the markup looks like -- is it just more xml tags binding to c++ objects or is there a higher level abstraction?
22:04:27 <JibberJim> SA: drag'n'drop photos etc.
22:04:39 <Hixie> robin: XForms, SVG, etc: they can all already be done in either HTML or Flash. Why would users switch to any of these?
22:04:42 <Chris> a smil editor written in flash running in ie to generate mms
22:04:46 <robin> Hixie: right, which is why the W3C must go off and create a WG because the industry is incapable of taking the Web to the next level on its own
22:04:48 <robin> :)
22:04:57 <Hixie> robin: what's the WG going to do?
22:05:13 <Hixie> robin: create another XForms, DOM3, or SVG?
22:05:16 <JibberJim> SA: Intro to LZX
22:05:26 <Tantek> SA: LZX - Laszlo's XML Language
22:05:28 <Hixie> robin: which will be implemented in UAs but not in IE, and thus not adopted by users?
22:05:29 <tvraman> Ian -- correct XForms plugins e.g. formsplayer are implemented in IE because it has the best XML stack -- but the kinds of things Mark Birbeck can show you are fundamentally different from what the average author can achieve in IE today. 
22:05:42 <JibberJim> SA: Demos Hello world app.
22:05:45 <robin> ditch the legacy, create an integrated profile of all the vertical stuff the W3C has been doing
22:05:54 <Hixie> tvraman: you can do anything xforms can do in IE today if you are willing to write enough script (and people are, apparently)
22:05:57 <robin> you start defeated
22:06:07 <Hixie> robin: who is going to bother using that product?
22:06:27 <robin> it needs be more than 10% better than what previously exists
22:06:34 <JibberJim> Hixie - we need to write script, the vendors haven't been up to creating interopable systems - no standards are going to change that, there will always be bugs in the systems.
22:06:40 <Hixie> robin: give me one reason, as a user, to switch to anything other than IE?
22:06:41 <robin> contrary to what moz, safari, opera etc have been doing
22:06:47 <vhardy> vhardy has joined #workshop
22:06:57 <JibberJim> Declaritive systems don't provide the way of coping with the errors in an implementation.
22:07:01 <tvraman> Ian -- because content is easier to develop. History has shown that at any point in time you only need one browser --- but there are millions of content creators  -- so define "user" if it is the luser who clicks buttons on the screen -- he doesn't care what it cost you to develop the web app -- but as the one paying the bill for creating and deploying the web app the app author cares
22:07:04 <robin> Hixie: give me a single reason to switch from the Minitel to the Web
22:07:10 <Yves> Yves has left #workshop
22:07:15 <Hixie> robin: the point is _users_ do not care about this stuff, and _authors_ can't switch to a new platform before users.
22:07:29 <tvraman> mais le minitel --c'etait vraiment bon!
22:07:30 <robin> authors have switched before users in the past
22:07:30 <dbaron> robin, the massive amount of content on the web?
22:07:34 <robin> tvraman:  :)
22:07:35 <Hixie> robin: colour
22:07:45 <robin> we have colour minitels!
22:07:51 <Hixie> robin: and what dbaron said
22:08:02 <robin> point is: if it's sufficiently better, *end-users* switch
22:08:16 <dbaron> robin, what makes it better is the content / applications that are available
22:08:18 <Hixie> but how are you going to do something better than IE? to the user?
22:08:22 <dbaron> robin, so the existing web has a lot of momentum
22:08:25 <robin> it's easy to see that one is dealing with HTML and trigger backcompat mode
22:08:48 <JibberJim> SA:  A language for web-apps need to have base level building blocks and standard UI controls.
22:08:51 <robin> dbaron: people swtiched from minitel to web well before the content was worth it
22:08:58 <Hixie> robin: Safari Mozilla and Opera all support XHTML. Yet there are almost no XHTML sites on the Web, despite all the advantages.
22:09:28 <JibberJim> TVR: How much Abstraction is there in the mark-up - are you going direct to underlying C++ or is there a higher level abstraction?
22:09:36 <robin> my point exactly, XHTML is an incremental improvment over HTML and no one cares
22:09:39 <JibberJim> There's advantages in XHTML?
22:09:55 <dbaron> the ability to do compound documents could be a major advantage of XHTML
22:09:57 <Tantek> XHTML is just a set of building blocks for XML.
22:10:06 <robin> just like CSS 2.1 is an incremental improvement over the CSS in IE, and no one cares
22:10:13 <robin> dbaron: right
22:10:27 <robin> but for that we need to get integration right
22:10:44 <dbaron> and we need languages to integrate that fit into the existing model rather than having new models
22:10:54 <JibberJim> TVR: Can I re-purpose the LSX markup for other UIs?
22:11:04 <JibberJim> SA: The backend uses Web services.
22:11:08 <robin> and probably heavily subset CSS/XHTML/SVG/XForms at least for v1 so that people can make implementations
22:11:11 <dbaron> and that don't duplicate existing features in slightly different ways
22:11:13 <Tantek> So folks developing their own XML languages *could* use elements from XHTML as building blocks instead of reinventing their own.  However, experience seems to show that folks developing XML languages prefer to reinvent many wheels every time.
22:11:16 <robin> dbaron: what's the existing modeL
22:11:18 <robin> ?
22:11:25 <jrandall> We're still making over $500 million per year on Minitel. People still use it.
22:12:13 <dbaron> robin, by the existing model, I'm referring to the details, mainly.  The way the SVG spec describes its formatting model is very different from the way CSS describes its formatting model, so it's very hard to know what's supposed to happen when they're mixed.
22:12:28 <robin> jrandall: and for good reason, the Web hasn't been sufficiently better throughout the board
22:12:38 <JibberJim> Don't mix CSS+SVG, they're both rendering languages.
22:13:04 <dbaron> JibberJim, but that *could* be the killer app to get people to switch to XHTML
22:13:12 <robin> dbaron: I can come up with ways in which they should be mixed
22:13:14 <JibberJim> David from LSX - you cann't re-purpose desktop direct to mobile easily.
22:13:25 <robin> and it's only normal that SVG would have a different model
22:13:32 <Hixie> (or rather, unless the majority of deployed browsers supported it)
22:14:02 <JibberJim> TVR: A user needs to interact with the service, it shouldn't matter what the medium is, we need commonality between communication between other systems.
22:14:26 <JibberJim> Lee Klotz Xerox, We noticed similarities with XForms.
22:14:49 <JibberJim> LK - have you considered using XForms instead of your own.
22:15:11 <jrandall> Minitel was always been designed to be an application platform, while the web was designed for documents. Also, the authoring tools for the web don't offer the same level of support for applications...
22:15:31 <MDubinko> Leigh Klotz
22:15:41 <MDubinko> s/Lee/Leigh/ that is
22:16:01 <JibberJim> SA: I'm no expert on XForms, XForms is about creating any UI from a particular dataset, whereas we want a specific UI.
22:16:03 <JibberJim> Sorry Leigh
22:16:25 <JibberJim> Vincent Mahe:
22:16:39 <dino> France Telecom
22:16:59 <JibberJim> VM: We need for mobile phones an integrated solution.
22:17:34 <JibberJim> [Green and orange on a white background, please pick a new slide master!]
22:18:10 <schepers> we'll, you should use User Stylesheets, Jim
22:18:12 <JibberJim> VM: We want to mix SVG+SMIL+XHTML profiles rather than anything new or extended formats.
22:18:58 <JibberJim> VM: We'd like a set of Classes of application, strict rules on integration and limit the allowed components in each.
22:19:05 <JibberJim> VM: we need more than just namespaces.
22:19:30 <JibberJim> VM: 3 predefined classes.
22:19:47 <JibberJim> VM Time Centric, Browsing Centric, Vector Graphic Centric
22:20:36 <JibberJim> VM: We don't want a subset of each language, we don't want to propose a set of tags.  the OMA needs a superset of W3 mobile profiles.
22:21:16 <JibberJim> VM: A homogeneous set of langs, with strict rules for scripting, styling and events.
22:21:31 <JibberJim> Presenter changes into John Trandell (sp?)
22:21:40 <JibberJim> Randall - sorry
22:21:46 <Steven> Josh
22:21:48 <JibberJim> Joshua Randall Sorry...
22:22:12 <JibberJim> Dynamic updating with remote events - we need events coming from the server rather than just the client.
22:22:22 <JibberJim> JR: We need this now.
22:22:26 <bert_lap> Interesting small print on the slide...
22:22:47 <JibberJim> JR: Web is request driven.
22:23:04 <JibberJim> JR: many apps simple reload themselves every N seconds, it's a polled web.
22:23:43 <JibberJim> JR: Polling is wasteful on resources.
22:23:47 <Hixie> here's a proposal for doing what JR is talking about: http://www.hixie.ch/specs/html/server-sent-events/server-sent-events
22:24:13 <JibberJim> I read that, but I didn't really get what the protocol was in that system?
22:24:18 <Hixie> HTTP
22:24:26 <Hixie> (or anything)
22:24:33 <Hixie> (doesn't really matter as long as it can stream)
22:25:15 <JibberJim> JR: Simple transport for DOM events from the server 
22:25:23 <JibberJim> JR: We need functionality now.
22:25:31 <JibberJim> JR: We're charging per kilobyte.
22:25:31 <tvraman> remember pointcast and the promise of push?
22:25:53 <Tantek> pointcast as a counterexample is a red herring
22:25:55 <robin> ooh 1996 all over again!
22:26:10 <JibberJim> What sort of like the keep open an HTTP connection and just drop events in it, why bother then having document orientated for a web-app?
22:26:13 <bert_lap> ... or change the pricing structure :-)
22:26:26 <JibberJim> Yeah bert_lap!
22:26:38 <JibberJim> Alex Hopmann
22:27:13 <Tantek> AH: Agree that polling is a problem.
22:27:16 <Hixie> JibberJim: yeah, just keep it open
22:27:17 <Tantek> AH: Web services standards can do this pretty well.
22:27:34 <robin> Hixie: thought of implementing that on top of http://www.w3.org/TR/SVG12/#network-data ?
22:27:35 <Hixie> JibberJim: not sure what you mean by the documents bit
22:27:56 <Tantek> AH: Actual protocol should be consistent with mainstream web services protocols that are being developed.
22:28:03 <Hixie> robin: why Scalable Vector Graphics are even _looking_ at that kind of DOM stuff is completely beyond me.
22:28:06 <JibberJim> Right, I find not using DOM events for that, just feed in script, the DOM just seems like another level of abstraction that doesn't help much in webapps
22:28:12 <JibberJim> What Alex is saying at the moment...
22:28:18 <robin> Hixie: because our users need it?
22:28:33 <Hixie> robin: so everything people want should go into SVG?
22:28:41 <robin> we'd be happy to have another WG for this sort of stuff, but there isn't so someone's gotta do the job
22:28:41 <JibberJim> Well, or CSS
22:28:51 <robin> rofl
22:29:08 <JibberJim> Dave Raggett - people are looking at this and it's underway.
22:29:19 <Tantek> robin, "there isn't so someone's gotta do the job" is no excuse to do work outside of a WGs charter.
22:31:44 <robin> Tantek: it's in charter
22:32:03 <robin> we need that sort of thing to implement XForms atop SVG, which is in our charter
22:32:09 <dbaron> robin, that attitude is exactly what's likely to keep SVG and HTML implementations separate
22:32:25 <JibberJim> MB: Polling is an HTTP feature not an Eventing protocol - that's a problem, but not an eventing one.
22:32:49 <JibberJim> MB: How do we allow one DOM to listen to events in another DOM?
22:33:11 <JibberJim> MB: Implementation isn't difficult.
22:33:37 <JibberJim> I thought XML events for other DOM was okay'd now in SVG changes to XML events?
22:37:04 <Steven> Good point from Leigh
22:37:09 <JibberJim> We all thank Leigh for minuting.
22:37:26 <Steven> where he says you can do the same thing but with simpler means
22:37:43 <Steven> (and mentioning an actual implementation)
23:07:11 <vhardy_> vhardy_ has joined #workshop
23:07:22 <MDubinko_> MDubinko_ has joined #workshop
23:09:27 <Steven> Steven has joined #workshop
23:10:07 <tvraman> nasty questions while we wait for John to reboot --- why is he running a machine that crashes?
23:10:28 <JibberJim> JF on non-presenter position papers.
23:11:04 <JibberJim> Access: no strong opinions, want predefined mobile profiles.
23:11:16 <JibberJim> Alex Danilo: uses a Virtual DOM
23:11:31 <schepers> schepers has joined #workshop
23:11:54 <JibberJim> Nokia: What's the complexity burden on combined vs seperate markups, how do we get short time to market?
23:12:19 <JibberJim> Nokia: Begin with use cases - efficient content authoring, interop and evolve in small steps.
23:12:58 <JibberJim> OpenWave: A mobile subset profile: XHTMLb SVGt CSSm ESm - custom component facillity like RCC (now XBL)
23:13:25 <JibberJim> Origo: XForms lays a foundation for apps. build on current work in HTML and XForms. 
23:13:34 <JibberJim> Origo - not profiles for compoutn docs.
23:13:42 <JibberJim> Origo: plug-in, plug in.
23:14:13 <JibberJim> Research In Motion: Standard Mobile profiles: yes - General extension arch not needed, "create a working group"
23:14:47 <JibberJim> SAP: Look ar RIML - XHTML2+SMIL+XForms - [only about 7 people know what RIML is]
23:14:56 <tvraman> And it builds on XForms 
23:15:26 <Chris> http://www2003.org/dd/t5_a1.htm
23:15:32 <JibberJim> RIML - Renderer Independant Markup Language
23:15:42 <Steven> http://www.w3.org/2002/07/DIAT/posn/nokia-ibm-sap.html
23:16:08 <JibberJim> SchemaSoft: tech probs from 2 years ago... everyone should read.
23:16:25 <JibberJim> SchemaSoft: SVG spec addresses some of the issues.
23:16:25 <Chris> also see http://www-124.ibm.com/developerworks/oss/consensus/
23:16:43 <Chris> "RIML consists of XHTML 2.0 + XFORMS 1.0 + SMIL CC + Extensions. "
23:17:24 <Steven> https://www.consensus-online.org/publicdocs/20031021-RIML-layout.pdf
23:17:36 <Steven> (Currently site is down)
23:17:55 <JibberJim> Patrick Schmitz: new paper from an hour ago, "The W3 must act decisively to reenergize the doc. presentation space or cede its influence to a few corps."
23:18:38 <JibberJim> Zoomon:  Deliberate process, focus on loose coupling of existing processes rather than new standards.
23:19:27 <mdubinko> http://www.w3.org/2004/04/webapps-cdf-ws/papers/SchemaSoftEmbeddingPaper.html
23:20:55 <JibberJim> CL: SVG Tiny is just a subset that you can implement on mobile devices, it still works on the desktop too.
23:21:07 <tvraman> tvraman has joined #workshop
23:21:38 <tvraman> label mobile/tiny is getting to be like low-fat and fat free in US grocery stores -- anyone tried to buy "full fat" yogurt like it
23:22:25 <JibberJim> XForms is based on XML Schema for validation, XForms basic throws out schema matching, just need simpler validation stuff - string matching.
23:23:30 <Chris> tv, you need to go to France to get full fat yoghurt
23:23:34 <Chris> http://www.w3.org/2004/04/webapps-cdf-ws/papers/SchemaSoftEmbeddingPaper.html
23:24:05 <JibberJim> Tantek: Various plugins knocking about that "implements" various stuff. in 1997 IE3 implemented CSS
23:24:30 <JibberJim> but 2001 was when we got IE5 mac that actually passed the test suite.
23:24:48 <JibberJim> These implementations are more like prototype impls.  What do they all really mean?
23:25:12 <JibberJim> CL: We need a thorough implementation test suite so we can see what's implemented.
23:25:29 <JibberJim> Tantek: If you want an implementation have a test suite.
23:25:49 <Chris> yes, the WG has to be involved with checking over the test suite
23:26:25 <JibberJim> TVR: IE"7" poorly tested, new W3 specs have good test suites, like VoiceXML
23:26:43 <JibberJim> TVR: and XForms of course.
23:27:05 <Chris> TV: we have learned from the poorly done or inexistent test suites
23:27:26 <Tantek> JibberJim, correction, _2000_ March was when we finally had an implementation that passed the CSS1 Test suite (IE5/Mac).
23:27:34 <JibberJim> Sorry Tantek.
23:28:02 <Tantek> np
23:28:06 <JibberJim> Glen - Ideaburst - we have most of the tools, we need to make it easy for developers.
23:29:51 <JibberJim> MB - can we define something and have it run anywhere.
23:31:46 <bjoern> bjoern has joined #workshop
23:32:05 <JibberJim> MB - We can't implement the SemWeb without a declaritive mark-up engine.
23:32:49 <JibberJim> Alex Hopmann: ask yourself - where do we care about Interop?
23:32:53 <Tantek> AH: Why and in what specific places do we care about interoperability?
23:33:13 <bjoern> rrsagent, pointer
23:33:13 <RRSAgent> See http://www.w3.org/2004/06/01-workshop-irc#T23-33-13
23:33:36 <JibberJim> AH: Should we just define data formats?
23:33:46 <Tantek> AH: Or do we define the types of data that these applications use so that the applications can be different and yet have the data interoperate?
23:34:35 <JibberJim> AH: We don't need to define an app that runs anywhere, we just need to define data that can be exchanged.
23:34:35 <Tantek> AH: There is all this neat innovation going on (Redhat platform, Apple platform, Microsoft platform, Mozilla platform)...
23:36:39 <Tantek> AH: End goal is to focus interoperability on where it helps (data formats and protocols).
23:36:44 <JibberJim> Bert Bos: It's not an either/or question - it's good to have plat. specific apps. but there are also cases where it doesn't make sense to write new applications on the system.
23:37:28 <JibberJim> BB: Every day applications need more adapted to the platform, infrequent applications web-apps are better.
23:37:44 <shayman> shayman has joined #workshop
23:38:07 <JibberJim> AH: webapps have good deployment characteristics.
23:38:31 <howcome> howcome has joined #workshop
23:40:38 <JibberJim> Glen: Ideaburst - I disagree... our experience is that web distributed apps is very valuable...
23:41:16 <Chris> on multiple platforms
23:41:17 <JibberJim> Glen: corp's don't have single platform standardisation, but want their internal apps to be maintained on just a single platform.
23:41:33 <Chris> even more true for mobile, indistrial users
23:41:43 <Chris> industrial
23:41:59 <JibberJim> Glen: It costs lots to develop Mac/Windows/mobile versions of the same product and maintain them all.
23:42:39 <JibberJim> Sun guy(?) We need to raise the bar from HTML forms, we need something richer.
23:42:48 <dino> Chet Haase
23:42:51 <JibberJim> thanks
23:43:08 <JibberJim> Owen Taylor.
23:44:19 <tvraman> and the answer to raising the bar on HTML forms and enabling richer functionality is .... you guessed it -- XForms
23:44:26 <JibberJim> People are interested in web-deployment, they want slightly more control than documents, but don't need to go all the way, different people want different amounts of developer.
23:44:49 <JibberJim> We need good rendering models for XForms, when do we get SVG+XForms rendering to customise the looks?
23:44:55 <Hixie> if xforms is the solution, why is the lowest common denominator html? xforms already is a REC, so surely that means this is a solved problem?
23:47:27 <dino> [Jon shows Adobe Visual Building Search]
23:47:58 <dino> Matt May: I didn't mean expose the whole Windows API, just the minimum stuff. People want this.
23:48:11 <tvraman> tvraman has joined #workshop
23:48:13 <dino> MM: This is not difficult.
23:48:24 <dino> MM: Can be styled to look like an OS (just like CSS)
23:48:38 <dino> MM: We can't just say the web is going to just be like *this*.
23:48:58 <dino> MM: We don't want JS libraries stuck in 1994.
23:49:04 <dino> Steven Pemberton
23:49:09 <JibberJim> updating UI without full reloading etc. is available across platform, across mark-up provided by script. the same script works in SVG and HTML and Flash...
23:49:27 <dino> SP: My question may sound agressive, but it isn't intended so.
23:49:37 <Chris> ... spit out the BUT, Steven
23:49:41 <dino> SP: I really want an answer.
23:49:55 <Tantek> SP: I agree that W3C should do declarative markup.
23:49:55 <dino> SP: You said we should do declarative markup. I think that is good.
23:50:12 <JibberJim> SP: XAML looks like SVG - why should we listen to what MS thinks we should do?
23:51:00 <dino> AH: Coming here I decided to be up front and say what we are doing.
23:51:09 <dino> AH: I was going to wear a target [joke]
23:51:32 <dino> AH: You may or may not believe me. I expect there will be a lot of disagreement with what I say.
23:51:52 <dino> AH: I've been in standards a long while. I've worked on them. I've seen success and failure.
23:52:19 <dino> AH: We have a bunch of graphics primitives in Avalon. They are the way that windows draws graphics.
23:52:20 <JibberJim> AH: I'm just trying to share my experienece - Avalaon is similar to SVG in some ways, but there's also distinct stuff.
23:52:33 <dino> AH: They go beyond what you want for interoperability.
23:52:40 <Tantek> AH: ... there is also stuff that goes way beyond SVG.
23:53:25 <dino> not way beyond SVG (iiui), way beyond interoperability
23:53:31 <dino> or did I mishear?
23:53:52 <dino> AH: XAML is direct mapping to .NET apis
23:54:27 <JibberJim> AH: It's just a replacement to GDI.
23:54:38 <dino> AH: Similar question as to why GDI doesn't support SVG. 
23:55:01 <AntoineQuint> But is a XAML file still a "document", or is it just a just a serialized XML API to .Net?
23:55:35 <dino> AH: There will be need for cross-platform apps running in the browser.
23:56:02 <dino> AH: As I understand it, the Adobe building thing targets the Adobe SVG platform
23:56:17 <JibberJim> AH: DOM spec is 221 pages
23:56:21 <dino> AH: If you look at the size of the APIs... DOM Core is 221 pages.
23:56:29 <dino> AH: The test suites are not valid.
23:56:29 <AntoineQuint> As an XML syntax it offers very few useful semantics and high-level constructs useful for efficient authoring
23:57:07 <dino> AH: It was hard work debugging the top 1000 sites.
23:57:43 <JibberJim> AH: how much easier would it've been teaching the top 1000 sites authors to write better markup.
23:58:48 <dino> Daniel Austin - Sun
23:59:05 <dino> DA: Java can solve all the problems that have been raised today.
23:59:08 <JibberJim> Hixie: earlier it was said ASCII was abandoned therefore HTML should be abandoned - note that UTF-8 is back compatible with ASCII.
23:59:10 <bert_lap> Antoine, Alex said in his talk that XAML is a programming-language-independent way of writing the constructor method of a class, and as such has the same semantics as writing it in C# or whatever language you're using.
23:59:17 <dino> DA: This is not a plug. Why don't people use Java?
23:59:56 <dino> DA: Is combining X-specs, is it going to be any simpler than Java.
23:59:56 <Tantek> DA: ... complexity ...
23:59:58 <dino> ?