IRC log of workshop on 2004-06-02

Timestamps are in UTC.

00:00:28 [dino]
DA: Are you making this problem look simpler than it really is?
00:00:31 [dino]
00:00:34 [JibberJim]
DA: Mobile guys want it to be simpler - can we making it simpler than the problems we have now.
00:01:03 [dino]
MB: Java could solve the problem, but to clarify...
00:01:08 [JibberJim]
MB: Java can solve the problem
00:01:13 [dino]
MB: Interoperability is very important.
00:01:27 [dino]
MB: It would be fantastic to write an applications and deploy to multiple platforms.
00:01:50 [dino]
MB: [compares to Pattern programming]
00:02:04 [dino]
MB: I want people to use that type of approach forWebApps.
00:02:17 [dino]
MB: Tax form is exactly the app you want to use a pattern for.
00:02:27 [dino]
MB: few simple business rules.
00:02:58 [dino]
MB: The Adobe VBS is just a heirarchical search pattern
00:03:13 [dino]
MB: Would be good to have a simple declarative language for this.
00:03:22 [dino]
MB: We are constantly reinventing the wheel
00:03:44 [dino]
MB: HTML worked because of cut & paste.
00:03:54 [Tantek]
and view source
00:03:59 [dino]
MB: How can we cut and paste a visual search? That's what we need.
00:04:18 [dino]
Laszlo guy suggests MB look at LBX
00:04:23 [JibberJim]
00:04:30 [shayman]
LZX it is
00:04:36 [dino]
whatever :)
00:04:36 [JibberJim]
Lots of talk about languages, nothing about runtimes.
00:04:54 [dino]
Laszlo guy's name?
00:05:04 [dino]
Laszlo: Java has not taken on the client.
00:05:06 [JibberJim]
"We love runtimes"
00:05:32 [JibberJim]
Laszlo: What's the loading order?
00:06:03 [dino]
Laszlo: We need to define the runtime. This is what XAML/.NET will do, but it is Windows only.
00:06:11 [dino]
John Boyer - PureEdge
00:06:37 [JibberJim]
John Boyer: we have Java now - a quick case study
00:07:51 [JibberJim]
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 [dino]
MM: Java didn't work on client because it was too slow. It is still too slow.
00:09:16 [JibberJim]
Matt May - the javascript player is adding weight to make it too slow. Why not put this functionality into the player.
00:09:48 [JibberJim]
[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 [JibberJim]
AH: CLI is an ECMA Standard
00:10:05 [JibberJim]
[334 IIRC]
00:11:16 [Chris]
as with most languages, the libraries rather than the language provide the real value
00:11:50 [JibberJim]
AH: People have created a fragile platform when you get advanced systems...
00:12:45 [JibberJim]
AH: getting features to a high quality is tough in declaritive situations.
00:14:03 [JibberJim]
AH: we can get to 80-90% before you need script.
00:14:12 [JibberJim]
AH: in form applications./
00:15:18 [JibberJim]
hakon lie: Java would've been a clean model, but it didn't work out - javasript won.
00:15:21 [JibberJim]
00:15:42 [JibberJim]
HL: We hate javascript as much as everyone else here. We can right neat javascript.
00:15:56 [JibberJim]
HL: Any spec W3 produces someone is going to abuse it.
00:17:07 [JibberJim]
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 [JibberJim]
TVR: Focus on the data.
00:17:49 [sac]
sac has joined #workshop
00:18:24 [klotz]
Peter ??? Adobe PDF manager?
00:18:31 [JibberJim]
Vincent Hardy: Java is a failure on the desktop - but it's on most phones.
00:18:39 [JibberJim]
Kandaces I think klotz
00:19:17 [JibberJim]
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 [JibberJim]
VH: API is very complicated!
00:20:07 [schepers]
00:21:47 [JibberJim]
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 [JibberJim]
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 [JibberJim]
Matt May: Sorry for giving impression Java was a failure...
00:24:05 [JibberJim]
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 [JibberJim]
MM: We need to ensure the people who are developing the web need the tools we need.
00:24:54 [JibberJim]
How do we get XHTML into IE?
00:25:44 [schepers]
that was IBM's Rich Schwarzfegger
00:26:25 [Chris]
.... existing HTML - not XHTML - existing infrastructure (ie, no new stuff) team is busy with security stuff
00:26:35 [JibberJim]
AHL we'll see how things pan out...
00:27:42 [JibberJim]
Rich: How do we get MS to address it - they're not in the WG for XHTML.
00:28:11 [JibberJim]
Tantek: We are in the XHTML WG, but they aren't doing what we want...
00:28:21 [Chris]
TC: proorities at MS are HTML4 eratta and a revised spec - not XHTML 2
00:28:43 [Chris]
SP: But that is your action item
00:29:28 [JibberJim]
TC: Where's the test suites, errata's etc.
00:29:37 [JibberJim]
TVR: Shouldn't you be doing this TC...
00:30:00 [JibberJim]
dino: bringing us back on topic...
00:30:26 [JibberJim]
Daniel, Sun: Any solution that we come up with that meets todays requirements will be really complicated.
00:30:44 [schepers]
David Temkin, Laszlo
00:31:19 [JibberJim]
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 [bjoern]
rrsagent, pointer
00:31:21 [RRSAgent]
00:31:30 [JibberJim]
DT: we don't need photoshop as a web-app.
00:31:58 [JibberJim]
Bert Bos: Most things are too simple for Java.
00:32:17 [JibberJim]
BB: Isn't the only reason java isn't used is that it's too much like a real programming language?
00:33:04 [Hixie]
Steven: note that XHTML 1.0 didn't even describe how it should be implemented until well after it was a REC:
00:33:13 [Hixie]
Steven: and that isn't even in a published document yet
00:33:29 [Hixie]
Steven: so the core of how XHTML1 is to be implemented depends on a post to www-html
00:33:43 [Hixie]
Steven: (which is pretty ridiculous imho)
00:35:55 [schepers]
Paul Topping, Design Science
00:36:06 [JibberJim]
MB - XForm like things normally get implemented again and again by huge teams.
00:36:35 [JibberJim]
PT: Every real declaritive application runs into a break wall that ends up needing imperative languages.
00:36:38 [JibberJim]
00:37:11 [schepers]
so do what you can declaratively, and solve the rest with script
00:37:20 [JibberJim]
PT: declaritive folk seem to want a simpler world than reality...
00:38:04 [Chris]
TVR: declarative allows the amount of imperative code to be reduced, goal is not to eliminate it entirely
00:38:22 [JibberJim]
TVR: use the scripting experience of the past to move into declaritive systems.
00:38:30 [schepers]
Steven noted that we should factor out the most common tasks, such as dependancy graphs, into declarative
00:40:31 [JibberJim]
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 [schepers]
Chet Huss, Sun?
00:41:48 [JibberJim]
Leigh Klotz - Maybe what we should be doing is XHTML+CSS+SVG+XForms client in Java, CLR, maybe flash.
00:42:05 [Chris]
sort of like XSmiles, which already exists?
00:43:04 [JibberJim]
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 [schepers]
seems that declarative is "safer" than imperative
00:44:57 [JibberJim]
We're winding up now... thanks to everyone... and we're closed.
00:45:50 [JibberJim]
Think about next steps over dinner.
00:46:08 [AntoineQuint]
AntoineQuint has left #workshop
00:54:02 [robin]
robin has joined #workshop
01:42:26 [bjoern_h]
bjoern_h has joined #workshop
05:00:46 [Hixie]
Hixie has joined #workshop
05:03:23 [bert_lap]
bert_lap has joined #workshop
05:15:33 [dbaron]
dbaron has joined #workshop
05:18:27 [Hixie]
Hixie has joined #workshop
05:19:59 [Tantek]
Tantek has joined #workshop
05:26:43 [tanteko]
tanteko has joined #workshop
05:27:46 [tanteko]
14:51:37 [RRSAgent]
RRSAgent has joined #workshop
14:51:44 [dino]
rrsagent, make logs world-access
14:51:51 [dino]
thanks buddy
15:41:11 [JibberJim]
JibberJim has joined #workshop
15:42:42 [Hixie]
Hixie has joined #workshop
15:43:23 [dbaron]
dbaron has joined #workshop
15:43:43 [AntoineQuint]
AntoineQuint has joined #workshop
15:44:31 [schepers]
schepers has joined #workshop
15:47:55 [dino]
bjoern, should be worky now
15:48:04 [bjoern]
yes, it does, thanks
15:48:16 [Dave]
Dave has joined #workshop
15:48:18 [dino]
it seems that rrsagent doesn't listen to me
15:48:33 [JibberJim]
That's fair though, neither do the rest of us.
15:48:41 [bjoern]
15:54:04 [mimasa]
mimasa has joined #workshop
15:57:53 [schepers]
schepers has joined #workshop
16:03:45 [bert_lap]
bert_lap has joined #workshop
16:04:03 [Steven]
Steven has joined #workshop
16:04:11 [heycam]
heycam has joined #workshop
16:05:26 [tvraman]
tvraman has joined #workshop
16:06:14 [MDubinko]
MDubinko has joined #workshop
16:11:16 [JibberJim]
Good Morning, and welcome to day 2.
16:12:07 [JibberJim]
RRSAgent, pointer
16:12:07 [RRSAgent]
16:17:29 [Chris]
Chris has joined #workshop
16:17:31 [bert_lap]
Good morning, JibberJim and everybody.
16:17:40 [jrandall]
jrandall has joined #workshop
16:17:40 [schepers]
good morning
16:20:23 [robin]
robin has joined #workshop
16:20:38 [dino]
who is running this show?
16:20:42 [dino]
what a mess~
16:20:44 [dino]
16:20:56 [schepers]
Steve Zilles asked what would mean that WebApps/CompDocs had gotten good enough to make a difference
16:21:32 [jrandall]
jrandall has joined #workshop
16:22:07 [Chris]
a possible answer - that there were authoring tools generating something that worked on multiple implementations
16:23:41 [JibberJim]
Schepers: It will be a success when people who were writing HTML in 97 are doing it.
16:24:03 [JibberJim]
Patrick Smitz: People don't have apps to say, they have things to say.
16:24:21 [JibberJim]
ChrisL: Users may want to produce apps that do something!
16:25:24 [JibberJim]
ChrisL: There's something more than interactive documents that people would want to provide, even without being a complete programmer.
16:25:51 [Chris]
CL: people may want to produce small apps that are more than 'interactive documents' but less than 'full blown programs'
16:26:10 [JibberJim]
Schepers: Webapps today are more complicated, but they could be small componentised reusable widgets that you can tie together.
16:26:32 [JibberJim]
Glen, Ideaburst: Code's crap but people use it, tools could exist that people can create webapps.
16:27:45 [JibberJim]
G, I: We spent most of our time on interface rather than creating applications.
16:29:28 [JibberJim]
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 [Chris]
I agree with John and he made my point better than I did
16:32:05 [shayman]
shayman has joined #workshop
16:33:14 [JibberJim]
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 [JibberJim]
^ That was Glen from Ideaburst
16:34:46 [JibberJim]
Teppo Jalava
16:35:48 [JibberJim]
TJ: shows SMIL/XForms - mixed docs are hard to read!
16:36:20 [JibberJim]
TJ: Timesheets are like CSS for temporal layout.
16:37:44 [klotz]
klotz has joined #workshop
16:38:15 [JibberJim]
TJ is demoing an app using a timesheets impl. in X-Smiles
16:41:08 [JibberJim]
Patrick Shmitz: Have you thought much about applying timesheets in compound docs and the issues?
16:42:11 [JibberJim]
MarkBirkbeck: Is CSS tied to the timesheet? Can you change more than just display?
16:42:21 [JibberJim]
PS: Yep you can change classes.
16:42:31 [JibberJim]
TJ: Yep you can change classes.
16:44:30 [JibberJim]
ChrisL: This is similar to something floated for DVD's XSS, what's the syntax?
16:44:36 [JibberJim]
TJ: XML/SMIL like.
16:45:11 [dbaron]
Hixie: cites
16:45:17 [JibberJim]
IH: CSS WG has been looking at this in CSS3
16:46:37 [JibberJim]
Erik Henmann on behalf of OASIS.
16:46:53 [JibberJim]
EH: data standard for compound docs
16:48:07 [JibberJim]
EH: DITA - Darwin information typing arch.
16:48:31 [Tantek]
Tantek has joined #workshop
16:49:07 [JibberJim]
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]
ph has joined #workshop
17:02:19 [dino]
Michael Pediaditakis
17:02:25 [dino]
University of Kent
17:02:34 [dino]
Slides at:
17:03:30 [JibberJim]
Proposing a Generic XML Presentation, see the slides!
17:10:28 [Chris]
alt and case look like smil switch, except for batch preprocessing
17:11:19 [JibberJim]
I like this, very much agree with "declaritive layers implemented imperatively"
17:14:11 [tjjalava]
tjjalava has joined #workshop
17:16:33 [dino]
Paul Topping - Design Science
17:16:38 [dino]
showing MathPlayer
17:16:40 [JibberJim]
On MAthPlayer
17:16:43 [dino]
no slides online yet
17:16:58 [JibberJim]
PT: It demonstrates some of the problems of plugins etc.
17:17:26 [JibberJim]
uses MS behaviours, DOM and loads of other interfaces in IE.
17:19:01 [JibberJim]
PT: very loud speech reader of the MathML content.
17:19:27 [JibberJim]
PT: means the screen reader or search needs to get through the multi-layers of the system.
17:20:09 [JibberJim]
PT: Ideally we want to implement mathplayer in all browsers using standardised interfaces.
17:20:51 [JibberJim]
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 [JibberJim]
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]
tjjalava has joined #workshop
17:23:27 [JibberJim]
[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]
Dan has joined #workshop
17:24:42 [JibberJim]
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 [JibberJim]
PT: Let's not start on XForms and XAML without learning from the past.
17:26:06 [JibberJim]
PT: Support for XML is not enough, need to allow support multiple vendors
17:26:29 [JibberJim]
PT: We need a cross-platform runtime, but don't look to a hardware vendor.
17:36:55 [Steven]
Steven has left #workshop
18:00:21 [jrandall]
jrandall has joined #workshop
18:02:49 [JibberJim]
Steven Pemberton on XForms
18:03:07 [JibberJim]
SP: More impls on day of release than any previous W3 spec.
18:03:25 [JibberJim]
SP: Lots of users, lots of vendors.
18:05:53 [JibberJim]
SP: data is one or more XML docs, input/output/memory model etc.
18:06:11 [JibberJim]
SP: Abstract input/output controls, impls can style it, or bound to SVG or ...
18:07:30 [JibberJim]
SP: Imperative vs declaritive - in 80's developed several clocks which had different views
18:07:42 [JibberJim]
SP: the shortest analogue clock in imperative was 1000 lines.
18:08:04 [JibberJim]
[it would be less than 10 lines of javascript in SVG]
18:08:51 [AntoineQuint]
where javascript = standards-compliant DOM scripting
18:08:54 [JibberJim]
SP: Shows simple ticking clock code.
18:09:10 [JibberJim]
Yes AntoineQuint
18:09:17 [naviuser]
naviuser has joined #workshop
18:09:18 [JibberJim]
SP: Some XForms impl just have the model.
18:09:29 [AntoineQuint]
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 [JibberJim]
SP: CSS or SVG for the impl, no commitment
18:09:50 [JibberJim]
Sorry Antoine, but I still want to make it respectable...
18:09:57 [bjoern]
18:10:21 [JibberJim]
SP: DI, Accessible, mostly declaritive but can be imperative.
18:10:23 [JibberJim]
18:10:24 [AntoineQuint]
JibberJim: I agree it is!
18:10:38 [JibberJim]
C# is also an ECMA Script language though bjoern now.
18:11:43 [JibberJim]
SP: Demos a couple of XForms examples
18:12:40 [JibberJim]
Paul Topping - design topping: Your rendering of one of the examples is poor? ...
18:12:53 [JibberJim]
SP: XForms is independant of the rendering
18:13:02 [JibberJim]
SP: CSS 3 and SVG will address this.
18:13:30 [Hixie]
(Well. CSS1 addressed the baseline issue back in 1996...)
18:13:41 [JibberJim]
Cameron McCormack: Can you effect things other than the XML model, e.g. CSS or positioning?
18:14:05 [JibberJim]
So it was a non-conformant CSS1 implementation in IE there Hixie?
18:14:16 [robin]
just use SVG :)
18:14:23 [Hixie]
JibberJim: i'd have to look at the exact markup to say, but yeah, probably
18:14:36 [JibberJim]
SP: Yep, but it's not really what it primarily designed for.
18:14:58 [Hixie]
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 [schepers]
clock: it would also be less than 10 lines of declarative code in SVG, not just script, JibberJim
18:16:17 [JibberJim]
John Boyer is demoing some games in XForms.
18:16:59 [JibberJim]
JB: Wizard like data entry for tax forms.
18:17:24 [robin]
schepers: you can't do the clock just declarative (I think)
18:17:59 [robin]
there's an SVG analog clock on fwiw
18:18:01 [JibberJim]
I think you can as long as they load it at a specific time...
18:19:17 [robin]
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 [JibberJim]
JB: doesn't matter which form I'm editing, the model reflects changes everywhere.
18:19:49 [JibberJim]
JB: Wrap the most appropriate host/rendering language around the rendering.
18:19:56 [JibberJim]
er the model.
18:21:54 [JibberJim]
JB: XForm skins are what we want to control the presentation.
18:24:20 [JibberJim]
Kelvin from IBM: how are you rendering this?
18:24:38 [JibberJim]
JB: We're using the Pure Edge XForms renderer - a plugin to the browsers.
18:28:16 [JibberJim]
Micah Dubinko on XForms.
18:29:33 [Steven]
Steven has joined #workshop
18:29:55 [shayman]
shayman has joined #workshop
18:32:36 [JibberJim]
Do we have a link to XForms basic?
18:32:48 [Hixie]
18:33:24 [JibberJim]
Robin, you also mentioned a good intro doc to this?
18:33:26 [Tantek]
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 [Tantek]
?? (from IBM): What is that people are screwing up with namespaces?
18:34:18 [robin]
I can't find it
18:34:24 [robin]
Leigh ought to know
18:34:24 [JibberJim]
Too many to fit in your head.
18:34:26 [Tantek]
MD: Namespace URIs are too long. More stuff than you can fit in your head.
18:34:29 [Hixie]
Chris, another difference is that xpath is way way more powerful than selectors
18:34:50 [Tantek]
MD: How XPath addressses Namespaces, doesn't use the default.
18:35:15 [JibberJim]
hmm, so if code size is important, throw out CSS and just use an XPath based selector styling system?
18:35:53 [Hixie]
unfortunately that would mean that the web didn't render, so it's not a viable business plan
18:35:57 [klotz]
XPath in Java is 85K bytecodes. Do a google search.
18:35:57 [Hixie]
(for a web browser)
18:36:28 [JibberJim]
well, didn't render so sweetly...
18:36:31 [Hixie]
klotz: including dynamic DOM changes in the face of script?
18:36:51 [Steven]
(Spontaneous applause; only the second this meeting!)
18:37:15 [robin]
JibberJim: I found something but unfortunately it's member only
18:38:19 [robin]
how about an XPath Basic that has just the information contained in CSS Selectors?
18:38:31 [robin]
then use straightforward conversion
18:38:31 [Hixie]
klotz: (and does it implement the xforms extensions to xpath? note that mozilla's xpath implementation is more like 300k)
18:38:38 [JibberJim]
Dave Raggett:
18:38:44 [robin]
björn managed the reverse very easily
18:38:55 [JibberJim]
DR: I'd like to break apps outside of the browser
18:39:03 [JibberJim]
DR: more various apps.
18:39:34 [JibberJim]
DR: cheaper, more flexible
18:39:41 [JibberJim]
DR: Easily adapted
18:40:26 [JibberJim]
DR: Author defined controls and Multi-modal interface
18:40:40 [JibberJim]
DR: Let people use their own XML
18:40:43 [dbaron]
actually Mozilla's is 170K (elf32 binary)
18:40:52 [dbaron]
(I just gave Ian an incorrect number a minute ago)
18:41:08 [JibberJim]
DR: Zinf demo - differently themed mediaplayer
18:41:50 [JibberJim]
DR: no chrome, windows irregular shaped
18:41:57 [JibberJim]
DR: Describe Object model in XML
18:42:28 [JibberJim]
DR: need way to close etc.
18:42:37 [MDubinko]
XForms validator is at
18:42:54 [robin]
XPath in pure Perl is 39k, including complete docs and installer :)
18:43:05 [JibberJim]
DR: This is beyond XForms, split UI into an abstraction and to a theme for pres.
18:43:09 [Hixie]
robin: and does _that_ work with dynamic DOM changes?
18:43:49 [robin]
no idea
18:43:57 [Hixie]
that's the hard bit
18:44:02 [robin]
hence my proposal to piggy back the CSS code that does that
18:44:24 [Hixie]
certainly using selectors instead of xpath in xforms would be an interesting thing to look into
18:44:30 [MDubinko]
but why is dynamically-updating XPath relevant to XForms?
18:44:34 [JibberJim]
DR: Layout intentions use SVG/XBL for delivering such controls, so we can create novel controls.
18:44:46 [Hixie]
MDubinko: because the whole point of xforms is that it is dynamic? :-)
18:44:55 [MDubinko]
(XForms has an explicit reevaluate-XPath-now step)
18:45:07 [JibberJim]
DR: Layout delegated down to the layout manager rather than doing it all yourself.
18:45:14 [robin]
I'd rather not have CSS Selectors instead of XPath in XForms
18:45:16 [heycam]
i looked at dependencies in xpath, to make sure expressions are evaluated when they need to be
18:45:16 [JibberJim]
DR: declaritive treatment of behaviour
18:45:27 [robin]
it would require all Full implementations to support both
18:45:33 [Hixie]
so drop xpath
18:45:35 [heycam]
it's not too difficult, but you do need to walk the path to work out which nodes are covered
18:45:36 [JibberJim]
DR: Simple event binding, state transition between named states.
18:45:54 [robin]
you can't drop XPath, it's extensible
18:46:00 [robin]
where CSS Selectors aren't
18:46:05 [Hixie]
sure they are
18:46:15 [Hixie]
mozilla and opera have both extended them
18:46:24 [robin]
that doesn't quite count :)
18:46:28 [Hixie]
why not?
18:46:30 [JibberJim]
DR: Could invoke methods or update data, or raise events.
18:46:32 [robin]
well I know of no implementation in which you can plug in your own functions
18:46:39 [Hixie]
that's an implementation detail
18:46:40 [robin]
whereas XPath has that all over the place
18:46:49 [robin]
no, it's also a specification detail
18:46:56 [robin]
XPath supports it natively
18:46:57 [Hixie]
(and in any case it is arguably one of the problems of xpath)
18:47:12 [Hixie]
anyway xpath and selectors do different things
18:47:19 [Hixie]
for example selectors has no equivalent of xpath true()
18:47:21 [robin]
given a defined svg prefix bound to a namespace, I can add svg:bbox(foo) and it'll work
18:47:28 [Hixie]
and can't do maths expressions
18:47:30 [Hixie]
18:47:32 [robin]
18:47:38 [JibberJim]
DR: we can treat all input uniformally as events.
18:47:44 [robin]
XPath is more an incomplete superset
18:47:52 [JibberJim]
DR: EMMA XML lang. for interpreted input.
18:47:55 [Hixie]
it's just a different language imho
18:48:06 [robin]
yeah but there's overlap
18:48:08 [Hixie]
18:48:20 [Hixie]
selectors is about going from an element in a dom, and a selector, and telling you if it matches
18:48:27 [Hixie]
whereas xpath is about an expression language that is dom-aware
18:48:28 [robin]
overlap that should be consolidated so as to make things using either more implementable on small footprint targets
18:48:47 [Hixie]
would have been nice if the xpath people hadn't reinvented the wheel, true
18:48:49 [heycam]
xpath for matching is just what is used in xslt
18:49:04 [robin]
yup, XPath does matching
18:49:18 [JibberJim]
DR: Various stuff already going on, Voice Browser folk, DI etc.
18:49:20 [JibberJim]
18:49:22 [JibberJim]
18:49:26 [Hixie]
well, it can return a node set, and you can examine the nodeset for membership
18:49:33 [robin]
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 [Hixie]
which means you can do matching with it
18:49:40 [JibberJim]
DR: use xml for descriping apps not jsut data - XBL and XForms
18:49:44 [robin]
Hixie: nope
18:49:48 [robin]
that's a usage detail
18:49:49 [JibberJim]
DR: Layout interntions, and what else?
18:50:15 [robin]
for instance XML::XPath has a matches(xpath, node) that doesn't work that way
18:50:18 [Hixie]
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 [robin]
it reads the XPath "in reverse" as it were and tells you it matches
18:51:17 [Hixie]
18:51:29 [JibberJim]
Schepers: What can't XForms do - what more does it need?
18:51:29 [Hixie]
so it in fact explicitly has some of the same goals in that case
18:51:40 [Hixie]
in which case it really is reinventing (and extending) the wheel
18:51:48 [robin]
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 [Hixie]
18:52:21 [Hixie]
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 [robin]
define the subset of XPath that is sufficient to express CSS
18:52:46 [JibberJim]
John Boyer: xml-sig, wrap it all up into a single doc is important
18:53:00 [robin]
use that in things like XForms Basic so that CSS implementations are basically reusable
18:53:07 [robin]
with minimal overhead
18:53:15 [shayman]
shayman has joined #workshop
18:53:23 [Hixie]
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 [JibberJim]
JB: ability to wrap attachments into the same underlying data.
18:54:12 [bjoern]
Why would they need to switch?
18:54:18 [robin]
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 [robin]
exactly, they'd never need to switch
18:54:52 [JibberJim]
SP: There's lots of more requirements coming in future XForms specs 1.1/2 etc.
18:54:54 [Hixie]
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 [robin]
it's just a smaller profile
18:55:17 [Hixie]
dino: it's off topic for web apps imho
18:55:25 [dino]
18:55:39 [Hixie]
robin: but as you know, i think profiles are bad :-)
18:56:00 [robin]
yeah, but I still have to hear an argument on that one :)
18:56:11 [Hixie]
david gave one in yesterday's presentation :-)
18:56:22 [robin]
which I missed since I flew in late...
18:56:35 [dino]
but we have lots of arguments on the positive side
18:56:35 [Hixie]
ah. then see
18:57:30 [robin]
18:57:37 [JibberJim]
TVR: XForms has datatypes and abstract layers - rather than a presentation
18:58:29 [robin]
that document conflates formats and profiles, I think that's stretching it
18:58:44 [JibberJim]
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 [Hixie]
i think the point is they are equivalent
18:58:56 [Hixie]
(to authors)
18:59:01 [robin]
I don't see it making claims supporting that point
18:59:10 [Hixie]
18:59:20 [robin]
and agitating XML Schema is too easy :)
19:01:48 [JibberJim]
SP: XForms is the intent of the structure, not the rendering.
19:02:45 [JibberJim]
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 [JibberJim]
SP: Yes we need a way to keep things seperate, but also need to package some how.
19:05:23 [JibberJim]
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 [bert_lap]
More about Dave's "layout intentions" to add to CSS: ideas about flexible "glue and springs" from XUL ( and grid templates, simplified from the NOTE-layout draft (
19:06:30 [schepers]
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 [JibberJim]
MB: Here's an XHTML 2.0 doc with XForms and then have it rendered in SVG or something.
19:08:40 [dino]
thanks to the irc monkeys for scribing while Leigh is at the mic.
19:09:27 [JibberJim]
MB: we can start spreading events to different applications that reflect the model.
19:09:51 [JibberJim]
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 [Hixie]
Peter from SE: We would implement inputmode if it was its own spec
19:10:46 [Hixie]
TVR: It is its own appendix!
19:11:05 [JibberJim]
Leigh Klotz: We're using XForms internally on lots of products. XForms+XHTML+XSLT works well on embedded
19:11:35 [JibberJim]
LK: you're not going to write DOOM in XForms.
19:12:20 [JibberJim]
LK: If you're sitting on SVG/XForms implementations get something out there please!
19:12:41 [schepers]
LK: I'm putting my money where my mouth is
19:13:06 [JibberJim]
LK: focus on what we could do with one out there.
19:13:51 [JibberJim]
CL: XForms could let the mobile guys make money, gamble, book tickets etc.
19:16:30 [JibberJim]
19:41:29 [bert_lap]
bert_lap has joined #workshop
20:31:47 [xover]
xover has joined #workshop
20:34:49 [robin]
robin has joined #workshop
20:36:02 [JibberJim]
Well we've just got a few more speakers, and then getting out into general discussion.
20:36:46 [bert_lap]
bert_lap has joined #workshop
20:37:14 [JibberJim]
Bert, will you be at Chaal's image desc meet next week? or indeed any one else.
20:51:23 [MDubinko]
MDubinko has joined #workshop
20:59:05 [Hixie]
Hixie has joined #workshop
21:03:12 [Tantek]
Tantek has joined #workshop
21:05:03 [JibberJim]
Cameron McCormack up....
21:05:21 [naviuser]
naviuser has joined #workshop
21:05:31 [JibberJim]
CM: First up, compound docs, we have profiles for a complicated combination of specs.
21:05:54 [JibberJim]
CM: We need some sort of extensibility to remove the scalability problem of having to do everything in a single UA.
21:06:04 [bjoern]
RRSAgent, pointer
21:06:04 [RRSAgent]
21:07:37 [JibberJim]
CM: we need to seperate out rendering that only needs to only implement parts and have other parts rendered to SVG as the base rendering environment as the doc using XBL like framework.
21:07:46 [Steven]
Steven has joined #workshop
21:07:49 [JibberJim]
CM: Give us a common framework for compositing everything together.
21:08:40 [Dan]
Dan has joined #workshop
21:10:04 [JibberJim]
CM: I've not read the all new XBL spec as it's not public yet...
21:10:12 [ph]
ph has joined #workshop
21:10:32 [JibberJim]
CM: how do events get handled can events get mapped into different events at different levels?
21:10:39 [shayman]
shayman has joined #workshop
21:10:45 [nms]
nms has joined #workshop
21:11:22 [nms]
nms has left #workshop
21:12:25 [JibberJim]
CM: now about layout for webapps.
21:12:59 [JibberJim]
CM: biggest SVG pain was layout. Laszlo layout was pretty easy
21:14:52 [JibberJim]
CM: we need some SVG suggestions
21:15:27 [JibberJim]
TVR: Your talk that for compound docs you want to map XHTML MathML etc. getting mapped to SVG compositing.
21:16:07 [JibberJim]
TVR: Will the XBL mapping maintain both DOMs so it's accessible.
21:17:06 [JibberJim]
CM: based on RCC sure, who knows on XBL
21:17:44 [JibberJim]
DBaron: The original DOM sticks around, you also get a 2nd tree of the rendering.
21:18:10 [JibberJim]
TVR: Can I be Tarzan jump from tree to tree?
21:18:15 [JibberJim]
CL and all: Sure!
21:18:56 [JibberJim]
Schepers: Layout in XBL is likely too expensive?
21:19:06 [JibberJim]
General agreement that it's better.
21:19:39 [JibberJim]
MarkBirkbeck: XBL that maps to XBL that maps to XBL that could map to SVG - it's a multi-layered thing.
21:20:45 [JibberJim]
MB: we need to keep the abstract later, and a shadow tree is already onto the renderer?
21:20:55 [MDubinko]
21:21:05 [JibberJim]
Cheers, apologies Mark
21:21:54 [JibberJim]
Hixie: We shouldn't let XBL etc. give us the chance to send proprietary mark-up over the web, focus on sending standards.
21:22:23 [JibberJim]
Glen Gersten, Ideaburst now.
21:22:28 [Chris]
Chris has joined #workshop
21:22:53 [JibberJim]
GG: We're hooked on SVG
21:23:04 [JibberJim]
GG: Some example webapps
21:23:25 [Chris]
facilities management application in SVG
21:23:55 [Chris]
21:25:00 [tjjalava]
tjjalava has joined #workshop
21:25:17 [JibberJim]
GG: Problems with HTML->SVG communication.
21:25:33 [Chris]
GG: proble4ms with integrating HTML renderers and SVG renderers - not crossplatform, no standards
21:25:45 [Chris]
'it works on windows'
21:26:10 [JibberJim]
GG: online ticket purchasing app, pricing and availability in an event in a show.
21:26:17 [JibberJim]
'only with IE'
21:26:52 [JibberJim]
regular HTML form that produces HTML ticket and map and info to print.
21:27:26 [JibberJim]
GG: A developer wouldn't want to creates progs to distribute, needs to work anywhere.
21:27:56 [Chris]
javascript execution error - resource scheduling
21:28:07 [Chris]
CL: use an svg Load event)
21:28:16 [JibberJim]
GG: dodgy script error, (to illustrate the need of cross "frame" events.)
21:28:54 [JibberJim]
I think he was illustrating that it needs to know that in the HTML document CL, rather than it not actually being possible to actually do.
21:29:15 [Chris]
mapquest-ng using svg (faster download and better quality than the real one)
21:29:33 [Chris]
yes JJ probably
21:30:21 [JibberJim]
now showing a facillities management svg tool.
21:30:43 [Chris]
well supported runtime environment
21:30:45 [JibberJim]
GG: What we need is a well supported runtime environemnt
21:30:48 [Chris]
true cross platform
21:30:49 [Chris]
21:30:53 [bert_lap]
Hmm, proprietary GUIs. Either it needs a "submit" button or it should not run in a browser. I hate things that look like forms but behave like applications :-(
21:30:54 [Chris]
easy to install
21:30:55 [JibberJim]
GG: fast easy to install and cross platofrm
21:30:57 [Chris]
well deployed
21:31:07 [Chris]
**** quality development tools ****
21:31:21 [JibberJim]
21:32:00 [JibberJim]
GG: we need standard widgets, layout manager, 2 way comms, windows, ready state checks, write and retrieve data from local client, and security/IP protection
21:33:25 [JibberJim]
GG: we need dev tools, Full fledged debugger, event tracking, performance optimisations, variety of runtime enviroments and extensible
21:33:35 [Chris]
GG: SVG needs more work in runtime environment area
21:33:59 [JibberJim]
Tantek: Standard set of interface widgets? what do you mean?
21:34:11 [Chris]
GG: real widgets (things that could bind to XForms abstract widgets)
21:34:23 [JibberJim]
GG: we need widgets that are rendered, rather than having to redesign everything each time.
21:34:29 [Chris]
Tantek references CSS3 Basic UI module, appearance property
21:35:31 [JibberJim]
Mark (?) : We don't need a standard set of widgets, we need a standard framework so look and feel isn't the same everywhere.
21:35:33 [Chris]
MV: look and feel has to be customisable
21:35:40 [Chris]
Marc Verstaen
21:35:45 [Chris]
, Beatware
21:37:15 [JibberJim]
GG: A standard looking widget, we just need something without having to write our own.
21:37:16 [Tantek]
I also pointed out that when the user navigates from one concert to another concert in the stadium application, the URL stays the same. What happens when you hit the Back button?
21:37:30 [Chris]
21:37:33 [Tantek]
The answer was, you go to the previous page before the stadium application. To which I said seems broken.
21:37:34 [JibberJim]
Sorry, yes Tantek - it seems just a criticism of that implementation...
21:37:38 [dbaron]
3 states for buttons? normal, :hover, :active, :hover:active, :disabled, ... ?
21:37:53 [Tantek]
No it is not a criticism for that implementation. It is the same problem as Frames.
21:38:17 [Chris]
AH: sliding scale of complexity, where do you stop.
21:38:27 [Hixie]
the problem tantek mentioned is definitely something that needs to be addressed for web applications, however complex they are
21:38:30 [robin]
Tantek: just ditch the browser :)
21:38:34 [Hixie]
(web applications _now_ have this problem)
21:38:48 [Tantek]
robin, this has nothing to do with the browser
21:39:17 [Steven]
Steven has joined #workshop
21:39:18 [JibberJim]
Yes Hixie, but I think that's a weakness of the implementations...
21:39:20 [robin]
the back button is a feature of the browser
21:39:40 [Hixie]
JibberJim: the web apps implementations, or the browser implementations?
21:39:45 [JibberJim]
the web app impl.
21:39:59 [Hixie]
JibberJim: sure, but it should be easier for them to work with that environment
21:40:08 [JibberJim]
21:40:28 [Hixie]
easier serialisation of state, e.g., and notification of "going back", "going forward", "came from forward", "came from back"
21:40:30 [JibberJim]
Doug Schepers? - Why SVG?
21:40:49 [JibberJim]
21:41:05 [Hixie]
'course i want to add that stuff to HTML. ;-)
21:41:40 [JibberJim]
DS:CSS cannot antcipate everything and we can't count on UA authors for everything, we need control over stuff to make our own UI's
21:41:52 [JibberJim]
DS: HTML is great for what it is, but it's not much good for apps, charts etc.
21:41:57 [robin]
imho it needs to go into a UA spec, not HTML
21:42:22 [JibberJim]
DS: we need keyboard events, we need to get to local files.
21:43:18 [Tantek]
robin, people want the back button
21:43:24 [JibberJim]
DS: Got to be some way around Security letting you write to files.
21:43:38 [Tantek]
people like being able to copy/paste URLs that contain state (like "this concert") and send them to friends
21:43:55 [JibberJim]
Yes Tantek, but "the UA navigation events" aren't document level - no need in HTML, they're UA level, and apply beyond HTML, a UA spec could address them
21:44:08 [Tantek]
some people might even *link* to such URLs, perhaps even on blogs. :)
21:44:24 [robin]
that being said, the UA events would be dead useful
21:44:47 [robin]
ASV has done some experiment with those, but it's not complete by any margin
21:45:06 [Tantek]
the point is, that that example (stadium), and many (most?) so-called web applications almost always break the user's expectations with regards to Forward/Back and URLs.
21:45:21 [robin]
on this we agree
21:45:30 [JibberJim]
I think we all do.
21:45:38 [JibberJim]
DS: we need save and resume ability
21:45:43 [robin]
I just happen to believe that it is mostly a problem with the browser not giving app authors sufficient control over that
21:47:13 [Tantek]
no, it is mostly a problem with authors using <a href="javascript:void(document.location='...')">... type gorp rather than using http URLs, fragment identifiers, etc. that work well with the infrastructure (favorites, bookmarks, forward/back, copy/paste etc.)
21:47:40 [JibberJim]
I thought authors were all authoring well structured XHTML+CSS now Tantek?
21:47:59 [Tantek]
the ones that are getting paid well are, in my experience
21:48:12 [Tantek]
never said "all", just the trend
21:48:27 [JibberJim]
Hixie: wouldn't it be better to integrate HTML and SVG better.
21:49:23 [JibberJim]
CL: how do we implement cross domain scripting in multiple platforms
21:50:09 [JibberJim]
location="..." leaves the back/forward button working anyway Tantek...
21:50:20 [robin]
SVG developers don't do the javascript URL style gorp, but they still can't do enough on the client side while also maintaining expectations re browser chrome and URLs
21:50:42 [JibberJim]
Steve Zilles:
21:51:36 [JibberJim]
SZ: I'm a doc guy
21:51:54 [JibberJim]
SZ: co-chair of XSL but also on HTML and CSS
21:52:34 [JibberJim]
SZ: Compound docs lead you into doing webapps
21:52:55 [JibberJim]
SZ: they need to put things together, and typically no product supports them all
21:54:26 [JibberJim]
SZ: mixing components - property propogation, event propogation, formatting and line breaking model, timing and animation, spell check, search, accessibility
21:56:04 [JibberJim]
SZ: a simple interface for property propogation can solve a lot, should be small
21:56:33 [JibberJim]
SZ: computed value of property, if it's inherited, and identify what properties it's interested in
21:57:37 [JibberJim]
SZ: who's in charge: Which "document"?
21:58:03 [JibberJim]
SZ: SMIL/XHTML/SVG/XFORMS all have reasons.
21:58:16 [JibberJim]
SZ: timing/the document/layout/interactions/
21:58:51 [JibberJim]
SZ: don't look at it that way, that's a mistake, which capability provider is in charge? the OS? The Browser? on a Platform independant VM?
21:59:08 [JibberJim]
browser's weak, a lot of interest in a Platform independant VM
21:59:18 [JibberJim]
SZ: what then should we be doing?
21:59:37 [JibberJim]
SZ: A practical combination of the various pieces and explore the VM idea
21:59:55 [JibberJim]
SZ: A combination of XHTML+SMIL+SVG maybe XFORMS ....
22:00:35 [JibberJim]
SZ: what the mobile guys have been looking at - this has an immediate utility, and it gives us the experience of integrating these few elements.
22:00:58 [JibberJim]
SZ: which will then give us the experience of a practical virtual machine
22:01:12 [JibberJim]
SZ: er experience to create a practical VM./
22:05:22 [JibberJim]
donkey sounds appear in the room.
22:05:50 [JibberJim]
we break for early coffee to give us a full last session to hammer out what to do,.
22:08:03 [tjjalava]
tjjalava has joined #workshop
22:24:00 [robin]
robin has joined #workshop
22:33:03 [tjjalava]
tjjalava has joined #workshop
22:37:14 [jrandall]
jrandall has joined #workshop
22:38:03 [tjjalava]
tjjalava has joined #workshop
22:43:26 [jrandall]
jrandall has joined #workshop
22:44:00 [naviuser]
naviuser has joined #workshop
22:44:04 [Chris]
Chris has joined #workshop
22:45:14 [JibberJim]
JibberJim has joined #workshop
22:45:29 [Tantek]
DA: Would like to mix all those things. Not sure about profiles though.
22:46:38 [Tantek]
TVR: Device specific profiles are a bad idea.
22:46:55 [Chris]
once again, small profiiles are not device specific
22:47:01 [JibberJim]
JibberJim has joined #workshop
22:47:11 [Chris]
xhtml basic is not mobile specific or device specific, etc
22:48:18 [Tantek]
PS: I don't like the term device specific profile. However, tiny, basic, is good.
22:48:19 [Chris]
PS: xhtml svg and smil as proposed in last session is a good set to start with
22:48:49 [Chris]
PS: next year we do svg basic
22:48:52 [Chris]
22:49:03 [Hixie]
chris, if SVG Tiny is not device-specific, why is the URI "" ? :-)
22:49:27 [Chris]
22:49:32 [Hixie]
uh huh :-)
22:49:44 [JibberJim]
Hakon Lie - we need a DOM, and a programming language for webapps.
22:49:57 [Chris]
agree with hakon
22:50:06 [JibberJim]
22:50:13 [bert_lap]
bert_lap has joined #workshop
22:51:05 [JibberJim]
JF: we should have a nice clean arch.
22:51:34 [JibberJim]
MB: We should combine things first so we get something to work, but we need a vehicle to bring them together?
22:51:49 [JibberJim]
MB: What's the mime-type for this type of doc?
22:52:21 [MDubinko]
22:52:30 [Tantek]
text/xml ?
22:52:39 [Hixie]
MDubinko: isn't that image/svg+xml ?
22:52:58 [JibberJim]
no, they won't give us application for SVG docs.
22:53:17 [JibberJim]
someone: We have DOM issues - we need a DOM WG.
22:53:29 [Chris]
text/* is deprecated
22:53:32 [Chris]
for xml
22:53:44 [MDubinko]
application/plain :)
22:53:46 [Chris]
several: DOM WG went away, its a problem
22:53:46 [JibberJim]
Steven Pemberton reiterates the point for work in the DOM workspace.
22:53:59 [Chris]
22:54:31 [bert_lap]
22:54:48 [JibberJim]
A Strawpool on SVG+HTML+SMIL+CSS+XForms
22:55:00 [JibberJim]
Robin Berjon - CSS is just a module of HTML [chuckle]
22:55:46 [Steven]
Steven has joined #workshop
22:56:01 [JibberJim]
CL: All proposals have taken an existing profiles SVGt+XHTMLb+SMILt and combined to do them.
22:57:09 [JibberJim]
AH: That's an interesting point - the existing specs aren't complete they don't give people interop - we don't need a new profile we need to improve the interop.
22:57:38 [JibberJim]
CL: yes, you need to do that for specs, but need to also ensure they work together so they can be proved with test cases.
22:57:56 [JibberJim]
CL SVG+SMIL+XHTML is an interesting enough test case to proof this.
22:58:09 [JibberJim]
JF: the biggest part is an interop test suite.
22:58:17 [JibberJim]
Hakon: Agrees to.
22:58:31 [schepers]
22:58:34 [JibberJim]
HL: microsoft, the specs are done, you can begin implementing...
22:59:04 [Steven]
22:59:04 [Steven]
Pot calling the kettle black? :-) )
22:59:15 [Chris]
now Opera have an offer of programming support from they can start, too :)
22:59:47 [shayman]
shayman has joined #workshop
23:00:09 [JibberJim]
Steve Zillis: working groups don't have enough time to integrate with other specs as tightly as they need to do it so a WG is valuable to give that time.
23:00:21 [JibberJim]
SZ: but are there the workers available to do it?
23:00:45 [Chris]
Charles Ying, Openwave
23:01:08 [JibberJim]
Charles Ying: The effort you start out with should be even smaller than SVG+SMIL+XHTML etc. perhaps just 2
23:01:18 [JibberJim]
CY: We'd suggest XHTML+SVG but we're mobile biassed./
23:03:04 [MDubinko_]
MDubinko_ has joined #workshop
23:03:07 [shayman]
shayman has joined #workshop
23:03:10 [Tantek]
CY: I really need a conformance test suite for that.
23:03:14 [JimJibber]
JimJibber has joined #workshop
23:03:15 [tjjalava_]
tjjalava_ has joined #workshop
23:05:04 [MDubinko__]
MDubinko__ has joined #workshop
23:05:05 [tjjalava_]
tjjalava_ has left #workshop
23:05:09 [heycam]
heycam has joined #workshop
23:05:09 [dbaron]
dbaron has joined #workshop
23:05:12 [klotz]
klotz has joined #workshop
23:05:18 [tjjalava_]
tjjalava_ has joined #workshop
23:05:20 [JibberJim]
JibberJim has joined #workshop
23:05:21 [naviuser]
naviuser has joined #workshop
23:05:24 [Tantek]
JF: Focus on external combination first, inline later. External is easier. Inline combinations have more issues.
23:05:38 [schepers]
schepers has joined #workshop
23:06:20 [JibberJim]
VH: It's hard to implement test guesses, who's going to do the work?
23:06:44 [JibberJim]
VH: take a humble approach limit the scope.
23:07:24 [JibberJim]
Do it quick...
23:07:39 [JibberJim]
next question:
23:08:14 [JibberJim]
Dino: If a WG is chartered to look at a virtual machine?
23:08:17 [jrandall]
jrandall has joined #workshop
23:08:36 [bert_lap]
Effective Web documents profile is more like HTML 4.01 (+ XHTML 2.0 (+ SMIL 1.0 (+ SVG tiny (+ MathML 2.0 (+ XForms 1.0 (+ CSS 2.1(+ PNG 2e (+ JPEG (+ MP3 (+ UTF-8 (+ HTTP/1.1 (+...))))))))))))
23:08:40 [Chris]
Chris has joined #workshop
23:08:40 [JibberJim]
Dino: declaritive is most welcome, but imperative important.
23:09:28 [mdubinko]
bert_lap, you should s/XForms 1.0/XForms 1.0 Basic/
23:09:36 [ph]
ph has joined #workshop
23:09:42 [JibberJim]
Dino: should charter a WG to work in this space?
23:10:58 [JibberJim]
Dan Austin: the first requirement for this Group would be to examine the requirements - the first thing they'd decide is that compound docs need to get solved first.
23:11:47 [JibberJim]
Glen Girsten: I'd be in favour to have a group, but it can't take a long time.
23:12:40 [JibberJim]
GG: existing spec's aren't looking at application space. need more info about what a runtime environment is.
23:13:06 [JibberJim]
Hakon Lie: FAST!
23:13:28 [JibberJim]
HL: I don't think this workshop could create 4 working groups...
23:13:43 [JibberJim]
HL: a group to create use cases would be a good starting point.
23:14:08 [bert_lap]
What are the other 3 groups?
23:14:12 [schepers]
correction: Hakon doesn't think it could start only 1 WG, but several
23:14:21 [dbaron]
I thought HL said that he doesn't think this ws could successfully create 1 WG, but could create 4.
23:14:33 [JibberJim]
sorry, that was very poor scribing!
23:14:53 [JibberJim]
remove "don't"
23:16:08 [JibberJim]
GG: there are a variety of problems and a compound doc isn't necessary before webapps work can be started.
23:16:31 [JibberJim]
GG: the DOM API is specified in a heavy way - we could convert the DOM to declaritive.
23:16:41 [JibberJim]
GG: XML events is a reflection of DOM 2 events.
23:16:54 [Steven]
Steven has joined #workshop
23:16:56 [JibberJim]
GG: XML events is more manageable
23:17:13 [JibberJim]
GG: referencing XML events spec is easier than referencing DOM 2 events.
23:17:25 [JibberJim]
me either
23:18:03 [JibberJim]
TVR: is the document the interface? should we be asking document or app?
23:18:16 [JibberJim]
TVR: It's not about inventing new, it's about stitching together.
23:18:27 [robin]
it may be easier for authoring tools, that's one thing I can think of
23:18:56 [Hixie]
TVR: Let's write use cases
23:18:57 [JibberJim]
I took it that he was saying SVG spec people had easier life because XML events existed?
23:19:08 [JibberJim]
TVR: find the low hanging fruit.
23:19:08 [Hixie]
TVR: Let's write actual web apps with angle brackets that are the use cases we have
23:19:25 [JibberJim]
TVR: no new spec needed.
23:19:27 [robin]
you mean the spec we patched? ;)
23:19:32 [schepers]
TVR: start with use cases, then end with test cases
23:19:58 [JibberJim]
Steve Zillis: Do we need to define what an app is, and if it's different from a doc - no it's irrelevant, what's relevant is what people need.
23:20:11 [robin]
JibberJim: it does make some things easier, for instance for sXBL in authoring tools. They don't need to run script to know which events are there, that sort of stuff
23:20:43 [robin]
or they could just run the scripts for the Bind* events
23:21:26 [JibberJim]
hmm, but if the script inside an event want's to start listening to another event (e.g. mousedown starts listening for mousemove) then they'll need to execute the script in the first one.
23:21:55 [Hixie]
dbaron: There are two problems: how to make the specs work together is a separate issue than how to get multiple implementations implementing difference namespaces
23:22:30 [Hixie]
dbaron: e.g. DOM Events defines how to do DOM Events across namespaces, and CSS defines how to do inheritance across namespaces
23:22:40 [JibberJim]
CL: I agree, but sometimes link you still want things to work, and sometimes you want to stop inheritence, you want to overide the normal difference
23:23:26 [JibberJim]
AH: Creating use cases for apps - I'm concerned they tend to be very simple, demonstrating we can build a calculator isn't much, you need to look at sophisticated things that people have tried to pull of.
23:24:19 [JibberJim]
AH: simple use cases won't answer the bigger question.
23:24:37 [schepers]
I don't necessarily agree with that
23:24:55 [JibberJim]
Mark Birbeck: on "we have the specs" the specs suggest you have 1 system which does it all
23:25:17 [JibberJim]
MB: but we have modular bits of software
23:25:28 [JibberJim]
MB: XForms might be too complicated for XForms...
23:25:31 [bert_lap]
Re "simple cases": but maybe simple and complex cases aren't solved with the same technology.
23:26:49 [JibberJim]
MB: the browser today doesn't provide the mechanisms for combining things to work together - CSS doesn't really say how a module knows it's green or red. we need to define how that the cross-module communication works.
23:27:14 [Chris]
dynamic infoset model - hmmm can you say more about that?
23:28:06 [JibberJim]
TVR: What did we conclude from those questions?
23:29:47 [JibberJim]
Straw polls on what needs to be done is suggested:
23:29:49 [Chris]
application/plain was suggested .....
23:30:49 [JibberJim]
LK: on XHTML+SVG+SMIL combination the only browser comm would be name value pairs.
23:31:08 [JibberJim]
LK: Is the complexity going to rise or fall if you combine or keep seperate?
23:31:40 [JibberJim]
er, that was Suresh from nokia sorry.
23:32:17 [JibberJim]
TVR: We've had the broad brush, we should identify specific problems
23:33:04 [JibberJim]
TVR: and solve them which will enable it to happen.
23:33:32 [JibberJim]
CL: hardware turnover quickly in mobile world gives us the chance to test and get users out there quickly.
23:33:50 [JibberJim]
CL: a crazy w3 browser gets 50 users worldwide.
23:34:04 [bert_lap]
On the MIME type for the profile: we need a more catchy name. Application/plain is a good joke, but something like Techdoc or Webdoc is easier to remember.
23:34:06 [JibberJim]
CL: 500 million phones gives us the chance.
23:34:32 [JibberJim]
Suresh - we need profiles rather than do everything spec.
23:34:49 [schepers]
and if it works on phones, it can work on the desktop
23:34:54 [xover]
bert_lap: If you pick a MIME Content-Type based on how "catchy" it is, so help me I will hunt you down and *kill* you! :-)
23:35:06 [JibberJim]
CL: the mobile down really push down what they want to implement, but what they implement they implement it all of.
23:35:40 [JibberJim]
Dan Austin: Profiles will increase the number Adhoc systems
23:36:14 [JibberJim]
DA: are we going to profilerate the number of specs?
23:36:49 [JibberJim]
Marc V. : Is the W3c interested in doing the work, as someone will do the work to integrate the specs other than the W3c
23:37:01 [JibberJim]
TVR: Does the W3 need to do the work?
23:37:23 [JibberJim]
CL: Vodaphone have stated that october's phones will ship with XHTML+SVG etc.
23:37:32 [JibberJim]
AH: isn't it too late?
23:37:34 [dbaron]
no "etc."?
23:37:44 [JibberJim]
23:37:59 [JibberJim]
CL:no not too late, software's still to come.
23:38:03 [tjjalava]
tjjalava has joined #workshop
23:38:19 [JibberJim]
CL: we need to specify this so that the vodaphone profile isn't unique, but covers other areas to.
23:38:27 [Chris]
we want a profile for all the vendors not just a single one
23:38:39 [Chris]
and we can learn a lot from building and testing it
23:39:00 [robin]
robin has joined #workshop
23:39:46 [schepers]
Rich S. from IBM: put authoring tool details in the Spec
23:39:59 [JibberJim]
JF: What %age of HTML is hand authored?
23:40:06 [Chris]
agree, authoring tool support is a success criterion
23:40:36 [Hixie]
why is "XForms" the only one that is underlined in red on dean's projection? ;-)
23:41:22 [schepers]
JF: agree, need good criteria for authoring tools
23:43:21 [Chris]
hixie - because his spell checker doesn't recognize it
23:43:28 [schepers]
Marc Verstaen, Beatware: we have the tools, that's not the problem
23:43:35 [bjoern]
RRSAgent, pointer
23:43:35 [RRSAgent]
23:45:53 [Chris]
23:46:03 [Chris]
a) XHTML.b + SVG.t
23:46:20 [Chris]
b) XHTML.b + SMIL.b + SVG.t
23:46:38 [Chris]
c)XHTML.b + SMIL.b + SVG.t + XForms.b
23:47:58 [schepers]
Question 2: Charter an incubator group to address: use cases for WebApps; roadmap (strategy for where to go); keep tool vendors in mind
23:49:04 [Chris]
rrsagent, pointer?
23:49:04 [RRSAgent]
23:51:35 [Chris]
a) XHTML.b + SVG.t + CSS.m
23:51:45 [Chris]
b) XHTML.b + SMIL.b + SVG.t + CSS.m
23:51:57 [Chris]
c) XHTML.b + SMIL.b + SVG.t + XForms.b + CSS.m
23:55:08 [CY]
CY: hmmm, i probably shouldn't suggest ECMAScript integration
23:56:30 [schepers]
yes! we need it! (JibberJim not schepers)
23:56:41 [schepers]
also schepers
23:59:56 [Chris]