*DRAFT* W3C Workshop on Web Applications and Compound Documents (Day 2) Jun 2, 2004

* Present

* Agenda

* Take the Steve Zilles Challenge

Steve Zilles: To repeat my challenge, can we find the key 5-7 things to focus on and not try to solve all the world's problems?
TV Raman: And how do you measure success?

Unidentified Speaker: I think success is when we have the same people who authored HTML in the 1990's do web apps.
Patrick Schmitz: I disagree -- there aren't as many people who need to expose functionality as those who just have something to say. I think that compound documents leverage the same framework as web apps, but they are different things. There are many, many more people who just want to say something. Chris Lilley: Those people do use software, for showing their family photos or talking to strangers for 10 minutes. A criterion for success would be buying inexpensive shrink-wrapped software that lets you author that. If you want something more complex, you have to be a programmer anyway. Some things are more than interactive documents and are in some sense applications.
Doug Schepers: Small applications can be aggregated into larger ones, a color picker and a graphics app for example, making a compound aggregate web app by people who aren't programmers.
Patrick Schmitz: Then it's constrained to people who have done CGI and PHP.
Glen Gerston: The web has lots of copied-and-pasted code. We could develop tools that allow people to generate that type of code, or have the runtime environment have standardized widgets with drag and drop and an app. We set out to make a facilities management app. It took about two months and we made it more extensible, easier to use, easier to maintain, and now it is two years. It's not easy to write interfaces from scratch. We need the tools to be able to deliver those types of applications in a short timeframe. We spent most of that time on our interface widgets. I'm sure the Laszlo people could tell you how long it took them to develop widgets in Flash. When the tools are there, people will start developing things.
Doug Schepers: That's the real revolution -- when people start using it.

John Boyer: I am not sure about Chris Lilley's point. Spreadsheet users are not programmers but they can leverage the power of a computation system to get their work done. One of our enterprise customers is converting 10,000's of forms over to this technology and the people who can use point-and-click are several pay grades below programmers.

Alex Hopmann: I am hearing lots of good comments; people are hopeful that it's possible to bring tools to people to let them do. That's nothing to do with this workshop. If you want to help non-programmers build things, like Lotus Notes or Apple Hypercards does, that's not where design by committee can help.
Glen Gerston: Everything is design by committee. We need file access, we need things that real applications have. There are security issues, but the problem can't be solved, or minimized. Having developed some SVG applications, it's not there for applications yet. We need more things to make it easier to do.
John Boyer: Alex's company and others produce spreadsheets; it gets this kind of stuff out to the masses. Standardizing business processes like this gives the underlying ability to create design tools to manage complexity.
Glen Gerston: Yes, we could resell our widget set, but it's slow and inefficient compared to a runtime environment. It's applicable to standards organizations. Dynamic layout management is computationally intense. Doing it like HTML tables is more efficient than in the running code.
Dean Jackson: Alex can respond in the next break.

* Jalava Teppo, Helsinki University of Technology

** Timesheets

** SMIL Problems

** Timesheets are like CSS

** Timesheets example

Jalava Teppo: Styling is done with CSS, time ordering done with timesheet sequence. XForms used, and then the HTML.

** Questions

Patrick Schmitz: Have you thought about compound documents, not just multi-namespace?
Jalava Teppo: We have just started on this project and have not done that work yet.
Mark Birbeck: Is the only thing that changes visibility, or is the CSS connected to the timeline?
Jalava Teppo: Yes, you can change the server class from the timesheet.
Mark Verstaen: We are putting in the same sandbox for the desktop, Excel and xxx. This approach is good for in-depth developers. For generalizing the use of SMIL, we need to have tools for the normal users of SMIL, not programmers; we need tools.

Chris Lilley: Very interesting presentation. Can you change type information?

Jalava Teppo: Yes, we use selectors.
Ian Hixson: You might want to look at the CSS WG presentation levels, which is not as powerful.

* DITA and Compound Documents, Erik Hennum, IBM User Technologies (presented for the DITA OASIS Technical Committee)

** What is DITA?

Erik Hennum: DITA is the Darwin Information Typing Architecture, an OASIS XML standard for human-readable topics (content objects). Evolving niches can be retired in favor of more general designs.

** Design composition from pluggable modules

** Inheritance of pluggable design types

** Benefits

** Aggregation of document content

** Summary

** Resources

** Questions

Patrick Schmitz: How about styling, event flow, and timing across compound document boundaries?
Erik Hennum: DITA takes a standard XML perspective of separating styling and presentation from content. It doesn't take a stand on timing.
Patrick Schmitz: In transclusion one author may prohibit change and the including author wish to control it. Similarly, interaction in sub documents vs. at the compound document level.
Erik Hennum: I don't think that DITA has addressed those issues, allowing application of the transcluded fragment to provide style or interaction hints to the transcluding document. It is an interesting question. I am glad you raised it.
Patrick Schmitz: How about fragment context when transcluding? XML fragment interchange...
Erik Hennum: Not addressed yet.

* Towards a Generic XML Content Presentation Model, Michael Pediatakis

** Applications VS Documents



Michael : A proposal

** Pre-processing with XMLPipe

** Summary

** Questions

Cameron McCormack: Do you use constraints for layout on different devices?
Michael Pediaditakis: We use selection constraints for templates for different devices. You choose the most appropriate one.
Mark Birbeck: I argued for a dynamic InfoSet in my paper; wiring in conditions and calculations and state automatically maintained. You want the same mechanism but different rules. I would argue for moving this into a module and do it without XML markup inline -- the rules up at a metalevel.

* Design Science, Paul Topping

** What is MathPlayer

** Demo

(Shows expression and then causes it to be spoken)

Paul Topping: Screen readers can read the web page and query the MathPlayer supports accessibility and use its math-to-speech conversion. The screenreader has to reach through the HTML to do this. Search is similar. MathZoom magnifies equations.

** Desirable: To be able to implemented MathPlayer in all browsers using standardized interfaces

Paul Topping: The font has to be taken from the enclosing paragraph and there is interchange between the widget and the HTML layout engine, unlike in displaying images. CSS doesn't deal with expressions in the middle of a paragraph and a comma. The comma flops down to the next line when you shrink the window. There needs to be a richer model for nested content, with role indicated.

Paul Topping: If an application needed to know that it could speak the math, or implement certain features, the server needs to know.

** MathML is a good usage case for compound docs

** Recommendations

** Questions

Doug Schepers: Have you tried using SVG fonts, which don't need to be installed and can be used as text.
Paul Topping: SchemaSoft did a MathML to SVG conversion; it might have performance problems and accessibility. Chris Lilley: To clarify, use SVG Fonts, not SVG. Use your own renderer, so it would help with baselines.
Paul Topping: We have the OS access and an installer so it can install fonts. SVG would not solve our problems.

Mark Birbeck: We have XForms using MathML inside hints and select1 in FormsPlayer with your MathML player, with nested content as you describe.

Paul Topping: I'm not up on XForms, but would MathML be able to specify its relationship with XForms if the label were an entire paragraph? Or a MathML expression with hats? Would it do enough formatting to know where the baseline is?
Mark Birbeck: I agree, you need the communication. The layout is done by MathML and we don't know what is happening. That is the same with the Adobe SVG player; it manages its space, but the space is controlled by the parent.
Dean Jackson: Let's pick this up again.
Paul Topping: Internet Explorer has an interface where we can specify the baseline and I'd like that on all platforms.
Mark Birbeck: I agree.

* Break

* XForms for Web Applications, Steven Pemberton, W3C/CWI

** XForms 1.0: en route to success

Steven Pemberton: On day of release, more implementations than any other W3C specification on day of success. There are major implementations from IBM, Novell, Oracle, Sun, xport.net, .... And major users from US Navy, Bristol-Myers-Squibb, Frauenhofer, Daiwa, British Life Insurance Industry, and more...

** The Central Idea of XForms

Steven Pemberton: The central ideas of XForms are that:

** Not Just for Forms

Although XForms comes from forms it is more:

Steven Pemberton: -Memory -IO -Calculation -Presentation

** Memory model

Steven Pemberton: The data is one or more XML documents, internal or external. Input, output, data properties, calculations...

** Input/Output

** Calculation

Steven Pemberton: Like spreadsheets, declarative. Uses XML Events. Usually don't need scripting, but still an option.

** Imperative vs. declarative

Steven Pemberton: In the 80's I build a completely declarative system. It ran on an Atari ST. I found a 1000 line analog clock code. Here is the declarative code for my clock (shows example about 20 lines).

** Presentation

Steven Pemberton: XForms can be hosted in different languages, use CSS for presentation, bind to SVG, etc. There are even model-only (no UI) implementations of XForms.

** Advantages

** Example forms

** Question

Paul Topping: I notice that the baseline of the text in the label doesn't match the label.
Steven Pemberton: I am running this in IE and haven't done any CSS control.
Paul Topping: Does XForms deal with it?
Steven Pemberton: We use CSS. CSS3 is adding properties to address the subparts of controls.

Cameron McCormack: Can the model affect things other than the controls? Can it affect CSS properties or positions?
Steven Pemberton: That's not the prime intention but you can see examples from Mark Birbeck.

* John Boyer, PureEdge

** Blackjack game

John Boyer: Here is my form, it is a blackjack game.

** 15 Puzzle

John Boyer: Here is another one, a 15 puzzle. We have made all these fun things with the same feature set as forms, and we view them as Webapp-complete.

** Tax Form

John Boyer: Here is a tax form example. There might be 10,000 pages of tax codes, but not for form 2290. We use the same form with the underlying model to drive the desktop appearance, the wizard appearance. Notice that all my information from the wizard is now in this traditional view. I declared UI bindings to the same underlying XForms processing model. We have some custom controls that understand things like phone numbers. For signatures, we have digital signatures using the certificates. Shows ("This is digitally signed and cannot be altered" popup on field.) The same underlying model drives all this stuff. Next button shows underlying rules in form filling in values in spreadsheet-like fashion and updating the rules for the document. It doesn't matter if I use the wizard-based version or the traditional version. Or an oral presentation -- it's the same underlying data processing model.

** What does XForms give you?

John Boyer: A container for the data, the relationships, their properties. Here is a required field which I have to either tab twice to get out of or enter data, because it is required. (Shows calculation of quantity, price, etc.) The host language extends the calculations. Our XFDL language allows you to control font color and image based on instance data. The XForms model gives us relevance -- when I select COD the credit card controls become invisible and unselectable (using XFDL to control the presentation).

** Dependencies

John Boyer: We can control relevance, which controls display and interaction. There are features for dealing with dynamic data such as adding to sets.

** Dynamic Rows

John Boyer: The computations are dynamic, now it is the sum of 5 rows.

** Attachments

John Boyer: If the attachment is a picture it is visible.

** Expanding Fields

** Signatures

** Questions

Kelvin Lawrence: How are you rendering this?
John Boyer: It is the PureEdge rendering agent. See http://www.pureedge.com/products/product/xdmos/xfdl/por.xfd for a demo.

Chet Haase: In your table demo with rows, it repainted the entire window. Is that an implementation detail? Was it going back to the server?
John Boyer: It was an implementation detail, and not going back to the server. It was an artifact of laziness in our rendering engine.

Doug Schepers: There is no visual depiction of XForms -- it is all underlying data? What we saw is not like HTML Forms, it is not a widget set, right?
John Boyer: To some extent. XFDL as a skin means that XForms has a "input" control and the basic purpose is user-based intent for collection of data. We can wrap an XFDL field around it; where the field is, or what font to use, is controlled by XFDL. But XForms provides the model.

* Micah Dubinko

Micah Dubinko: These are my personal opinions, not necessarily endorsed by my employer.

** Communicating Data

Micah Dubinko: To communicate data, you need a rich addressing system. Early drafts of XForms used new inventions, but as that went through the gauntlet of W3C process, it was replaced with stuff that people already know. It started with a multi-year process.

** XForms could be better

Micah Dubinko: It needs to work with script better.

** Namespaces are very difficult for authors

Micah Dubinko: I get email about my book with XForms that doesn't work. At least 4 out of 5 are problems with namespaces -- declared, or used with XPath. I wrote an interactive validator using RelaxNG and some document scans based on XPath. You can access this from http://www.xformsinstitute.com But namespaces are a problem. Anything that comes out of the W3C will use them. In the short term, expect your users to be noticing this pain. We might be seeing some workarounds. For a longer term solution, if you are feeling this pain, make yourself heard more and take it to the highest levels in the W3C.

** Summary

** Questions

Håkon: I agree with you and I wish I could find a way for Opera to support XForms and it was too complex. I feel that authors will have a problem with XForms as it stands now. What could we do with the Basic Profile? Could you remove namespaces and XPath? Just a pointer mechanism instead of XPath?

Micah Dubinko: I think the direction with your suggestion is good; we could build bridges. There is good work still to be done. Chris Lilley: I am puzzled by why mobile developers can do selectors but not XPath? Håkon: That's like saying you have done JavaScript so you can do more. Chris Lilley: So it's code size?

Kelvin Lawrence: Could you say more about namespaces? It it hand coding?
Micah Dubinko: From the errors I have seen, namespace URIs are really long and you need a lot of them and you can't fit them in your head. XPath and Namespaces are a problem -- XPath doesn't use the default namespace. The boundaries between two different namespaces are also a problem.
Mark Birbeck: We touched on these yesterday. <p><b></p></b> Should we not insist on fixing that? We need to make it easier to author. We just have to live with namespaces. I will give Opera a hand in implementing XForms in Opera if necessary; we can knock it out in a week if XPath is the problem.

* New Directions for Web Applications, Dave Raggett and TV Raman

Dave Raggett: These are my views not Canon or W3C.

** Goals

** Theming

Dave Raggett: Zinf media player on Linux -- one application, three themes. The presentation is separate from the underlying application.

** Break free of the Browser

** Describe object model in XML

Dave Raggett: This is beyond XForms.

** Themes and Intentions

Dave Raggett: Ask Mark Birbeck about using SVG to render an XForms thermometer form control, a novel control.

** Declarative treatment of behavior

** Multimodal Interaction

** Mixing Novel and Standard Markup

** Who's doing what?

Steven Pemberton: Give Leigh first choice?
Dean Jackson: Do you run Linux?
Leigh Klotz: Yes.
Dean Jackson: You get one choice -- the book.

* Break

* Cameron McCormack

** Compound documents

Cameron : We have profiles for XHTML+MathML+SVG, etc. But to get some extensibility, you don't want to have to construct a new browser. That's where XBL comes in. Then we have a framework. You get plugins with a blank white square, but you can't get much interaction between the different parts of the document. If everything was converted to SVG at the base level then you could put MathML in. So use XBL and make up your own elements. We need to take note of how the parent document does its layout: for example, XHTML has the CSS box model and SVG has things where you put them.

** Questions

TV Raman: So you say if you need a compound rendering model for MathML and XHTML and so on, map it all to SVG and then use XBL. Mark Birbeck raises the accessibility issue. If you map it to you an SVG canvas, that just gives me PostScript + Eventing, essentially News from the late 1980's. Do you have any thoughts about how to preserve both DOMs? The range control in XForms that you map onto the spin dial tells me what I need, not the SVG DOM.
Cameron : The way it was is that each element had a shadow tree attached to it, as the SVG that it equated to. The rendering could be a separate tree, but you have to keep them in sync.

David Baron: The way XBL works is that the original DOM tree stays around. It gives you additional content nodes and the original DOM API navigates the original DOM tree, and a second DOM for the rendering tree with additional or different content.
TV Raman: Then do I play Tarzan and jump from tree to tree?
David Baron: Yes, but you don't have to.

Glen Gerston: The original is not lost. In terms of layout, you mentioned XBL. Probably declaratively, the runtime rendering engine would be faster to handle it directly.
Cameron : Probably yes for grid layouts.

Mark Birbeck: On the two trees, it's not just the shadow tree. There may be intermediate steps, for example an abstract control. An input control on an IP address can be four further controls that themselves are abstract. Can that be solved with a shadow tree storing the four inputs and then a shadow tree on each input?
TV Raman: Recursion gets harder with the shadow tree approach.
Mark Birbeck: You need the abstract binding on the source side and the rendering model then itself might have a shadow tree, but that's a separate issue.
Ian Hixson: With XBL/RCC, we shouldn't let those technologies be a temptation to send proprietary markup over the wire; you should send XForms or whatever.
Cameron : If you have the means to convert it to what you know then what is the problem?
Dean Jackson: Thank you.

* Glen Gerston, Ideaburst

** What do developers want?

** Background

** Fonts

Glen Gerston: Adobe sells fonts; they have to make a GIF for their type faces on a regular basis. So instead we have an app embedded in an HTML page, enter text, and a point size and get a sample. One problem is that the runtime environments don't play well with the browser. It works in IE on a PC but not on a Mac. That's a major problem.

** Tickets

Glen Gerston: Here is an online "Adobe Arena" ticket purchasing system. It downloads data and you can roll over the sections and see what's available, or change the event. We get a running tally, and a form to buy, and then we get a printable SVG ticket. We can cut and paste directions, and zoom in on the map.

** Mapquest

Glen Gerston: We got an error because the JavaScript tried to insert into the SVG before it was rendered. We can pan and zoom without reloading, and raw on the map. We can do overlays. The artist drew this in Illustrator and the programmer hooked it up.

** Programmatic views in client

Glen Gerston: You can't use pre-defined interfaces, so we need interface widgets. This opens in a new window, from the browser. The content resizes and we can switch tabs programmatically.

** What Developers need

** Runtime Environment

** Development tools

** Questions

Joshua Randall: Do you want these in SVG or just somewhere?
Glen Gerston: We think that the SVG runtime could be made to do it but we could see it elsewhere.
Tantek Çelik: On the runtime environment, the standard set of widgets, do you mean semantic or visual?
Glen Gerston: Visual widgets. Tree views, menus, phone interfaces, etc.
Tantek Çelik: Take a look at the CSS 3 basic user interface module appearance property.
Tantek Çelik: In the stadium example, the URL stayed the same, even from one concert to another. What if I click the back button.
Glen Gerston: It goes back to the previous page.
Tantek Çelik: That seems broken.
Glen Gerston: That's a problem of running in a web container.

Mark Verstaen: The look and feel of the widget has to be customizable. You enter the framework war then. Now we have tons of frameworks from Microsoft, Apple, and others.
Glen Gerston: We would like to see even standard looking widgets, perhaps customizable with CSS. To us having some standard set of objects would be good. Our interfaces are obviously very stylized, but we could create applications.
Mark Verstaen: Customizing a widget is not just the look; for a widget you need three animations. For a tree view, you have the mouseover effect, etc. It's endless.
Alex Hopmann: Raise your hand for button, checkbox, slider, date picker, etc. The spectrum is an application platform thing. Standards groups are poorly suited to come up with ones for everyone.
Dean Jackson: Let's end this.
Leigh Klotz: The best is the enemy of the good.

* Doug Schepers

** Why WebApps?

Doug Schepers: SVG is a great medium to deliver WebApps. I agree with Glen that we need a set of widgets. We do not need them to be automatically provided. Even if you have sliders, do you want them left, right, top, ticks?

** Why SVG?

CSS can't do everything. XBL is for that. UA builders will not get every widget right; the authors need core-level building blocks. Not just mouse-move events, but resize events on controls, not just the canvas.

** Why not HTML?

HTML isn't well suited for the wide variety of user interfaces that may be needed such as charts, maps, and groovy bits.

** What do we need for SVG?

** Questions

Ian Hixson: You said that HTML and SVG didn't work together. Shouldn't you make them interact better rather than adding the features together?
Doug Schepers: Absolutely. With the SVG plug -in they won't work well together. Like everybody else here I want to hear that they all work together. Chris Lilley: Adobe says that the plug-in works in some platforms but not others. Tantek said there was no W3C spec to implement it.
Tantek Çelik: That was a few years ago. Chris Lilley: Is there a spec now?
Tantek Çelik: No. Chris Lilley: So how can we do it?
Doug Schepers: I think we need them in SVG and we need them soon.

* Steve Zilles

** Background

Steve Zilles: I am retired from primarily IBM and Adobe but am presently an independent consultant. I was co-chair of the XSL 1.0 WG and have 20 years experience of working with documents, and worked on HTML and CSS, and am a document guy rather than a Web App guy. It turns out if you want to do compound documents in a practical way, you come back to web apps.
Steve Zilles: Compounding means a lot of things together: text+graphics+math is a simple example. Chemical formulae is another. No one vendor wants to do them all. Authors need different subsets. Compound documents inherently compound things that don't come from the same place.

** Requirements for mixing components

Steve Zilles: The first four I already knew and the last three are new from this meeting.

** Propagation

Steve Zilles: An interface that, given a property provides APIs

** What/Who is in charge?

Steve Zilles: Which document?

Steve Zilles: It is a mistake to say that any one of them is in charge. The more important question is where the capability is provided.

** What should happen?

Steve Zilles: A two-pronged approach

** The practical combination

A combination of XHTML, SVG, SMIL, maybe XForms... Reasons Should no assumption that any one component is in charge; a monolithic approach.

** Can we do a practical virtual machine?

** Questions

Daniel Austin: Who is in charge? Consider a set of rules associated with one of the components is in force at any time.

TV Raman: I agree that of the things that want to be in charge, they should be daisy-chained. In the list, though, XForms definitely does not want to be in charge. Do you have thoughts on a VM that would be an XML browser and could dynamically bootstrap itself, so it wouldn't be monolithic?
Steve Zilles: No, I'm a document guy and I don't have an answer. The collected intelligence from the room does have thoughts...

* Break

* Final Session

Dean Jackson: We will have ten minutes per question for staged discussions and then 30 minutes of open discussions. Here are my proposals:

** Should the W3C to provide a profile of XHTML, SVG, SMIL, CSS, and XForms?

Daniel Austin: I don't agree with device specific profiles. I think we should find the best solution to this problem, not in a way specific to a certain class of devices.
TV Raman: I think we should factor the question of device specific profiles (a bad idea) from the low-hanging fruit of bringing together a group of W3C specs. If we don't bring them together, perforce SVG will develop little bits of XForms. etc. These two problems need to be factored.
Peter Stark: The W3C should take the lead in showing how the SVG, HTML, and SMIL should be combined. I support that SVG/XHTML/SMIL is a pragmatic approach and an urgent need. On device specific profiles, I don't like the term. SVG, XForms, etc. should have different conformance levels so the industry can support them incrementally. Håkon: For compound documents yes, but application developers want DOM. If we do web applications, we need Turing completeness.
Jon Ferraiolo: You have to think about who is talking -- Peter from Sony Ericsson is in the industry and has an urgent need from his industry. Others want a nice, clean architecture. Let's do that on a grand scale, but let specific industries solve their needs. As Dan said, if we don't do it, someone else will do it and W3C won't lead the web.
Mark Birbeck: The first task should be aggregation of what people are already trying to do. I'm not sure what a profile means, but an if it is an aggregation, yes. But then through what vehicle to bring it together? We don't know the answers, but one of the questions from before Cannes is the MIME type, for example, unmentioned this week. It isn't obvious that we will quickly resolve it. Start with the vehicle with the bigger picture, but we will address even more issues that fall out. Let's bring people together and see how problems in SVG and XForms communicate and make that a requirement for the bigger WebApps thing.
Rich Schwarzfegger: We have errata in the DOM working group. Let's fix that.
Steven Pemberton: Within W3C, DOM is a central part of our technology and not having a DOM WG is a problem. We need someone to own that space.

** Straw Poll

Dean Jackson: Should the W3C provide a profile of XHTML, SVG, SMIL, and possibly XForms.
Leigh Klotz: CSS?
Dean Jackson: Should the W3C provide a profile of XHTML, SVG, SMIL, CSS, and possibly XForms.
Alex Hopmann: A limited restricted profile?
Dean Jackson: I don't think it means all possible variations. Chris Lilley: All the existing proposals have taken XHTML Basic, SMIL Basic, SVG Tiny. But then in great detail for interoperability -- width and height on image, etc. The glue that is missing.
Alex Hopmann: That touches on what I feel, that a lot of the basic specifications are not complete yet. They don't give interoperability. We don't need a specific profile; rather, we need to get the specs of these test suites and normative detail right to solve the initial goal of interoperability. Chris Lilley: Yes, that's necessary but not sufficient. You need to check that they do fit together.
Jon Ferraiolo: The biggest activity would be the interoperability test suite. Håkon: The specs are done...
Tantek Çelik: We are missing the test suites, though. Håkon: They all have good benefits; is this tiny, or what? Do we cut down or do a mega thing?
Steve Zilles: I think the main reason why a combination is important, is that despite the interest in the best working groups, there isn't sufficient time to explore the cross-WG issues. The main value is a forum for addressing the issues that go outside an individual working group's purview. For the straw vote, would the people who care about this man the working group to do this thing? It won't be individual test cases for the specs. In the property set, divergence happened because there was insufficient conversation, not malice aforethought.
Charles Ying: I think the effort should be smaller. Test suites are an excellent start. The scope should be deliver the integration of two fronts -- XHTML and SVG. That's for our market; it depends on who is in the effort.
TV Raman: I want to re-emphasize the focus on combination and not the profile issue. There are examples of two: XHTML+ MIME document. When I wrote the XHTML+Voice profile I looked at it and it is a good document. Three gets more interesting not at the DTD or Schema level, but at the processor level. Final, let me echo Steven Pemberton and Rich Schwarzfegger's DOM issue.
Charles Ying: We also need an accurate conformance test suite, use cases, content developers, etc.

Glen Gerston: Do you mean an embed or mixed-namespace?
Jon Ferraiolo: When I gave the Adobe position paper, I suggested that keeping it small would focus on external combinations, not inline. The external one is easier. You don't have to worry about CSS styling across boundaries, for lower-hanging fruit.

Vincent Hardy: Look at what it takes to develop the specs. We tried to make a case about what happened with implementation complexity. Bigger profiles are harder. This is orthogonal to target devices. For SVG, Tiny is more successful because of the mobile industry, but also because the implementation barriers are lower. Still it is too high. For the WG, it is hard to get people to take minutes, do test suites, review specs, etc.

Scott Haman: I would like to echo Charles, Vincent, and Jon. Small steps. Carriers are doing it. We need five years to pull everything back together.

Dean Jackson: We couldn't vote on the straw poll because we could not define the question.

* Steve Zilles's Two Proposals

Dean Jackson: Let's suppose that a WG is chartered to examine Web Applications requirements; Steve used the phrase "virtual machine."

Daniel Austin: Is that the cart before the horse?
Steve Zilles: I said create an incubator group, not a working group. It is a lighter weight, for requirements, use cases, and implementations of the pieces for a more formal process.
Daniel Austin: The first requirement for the group for requirements would be solving the compound document problem. Web Applications are the cart and Compound Documents the horse. I can have one that isn't the other. Then tackle them in the sequence we need to solve them. We can't solve the Web App problem without first solving the compound document problem.

Glen Gerston: I am in favor of a group, but 2 to 3 years won't help. We need a specification for a runtime environment to say what it has to pass. Håkon: Use cases is a better starting point for stakes in the ground; we need to work quickly.

Mark Birbeck: The compound document problem is many problems in different contexts; editing, potential shape for guiding the user. People draw a distinction between the documents and applications. There are some things such as the MIME type question, but in the main the problems are inseparable. On the Virtual Machine, I suggest that we aggregate what we already have. Take the DOM spec; it is a virtual machine. It is specified in a heavy way, as an API. I think a declarative markup version of the DOM API, as done with the XML Events specification, is a good idea. It is more manageable and easier to incorporate into other specifications. For factoring, it becomes easier to build on top of the specification. I propose only one new module, system (closing applications, clock, etc.) Everything else already has a corresponding feature.

TV Raman: There are enough Xeroids in the room to ask, is the document the interface? In 30 years will we still be asking this? We have had discussions during the W3C QA about how to write specs where the test cases drop out. So, take existing specifications such as SVG, XForms, SMIL, and stitch them together. Let's write actual angle brackets at the start, and at the end the test cases. Solve the low-hanging fruit first: MIME type, loading into a DOM, initialization, propagation of events. If solve those four, then how to package them. There is no new spec here.

Steve Zilles: My comment is on the issue of do we need to define what an application is? Or is an application different from a document? My answer is that it's irrelevant and doesn't matter. What facilities do we need to get work done? Mark just needs the facilities to write the code to get the work done, and the prospective incubator should be focused on that.

David Baron: There might be confusion between how compound documents should work and an API such that different programs can implement different languages within the compound document. The DOM 2 spec says how events propagate, and CSS says how cascading imperatives work, without namespaces. The issues are more about the API of how to do that with multiple implementations. Chris Lilley: I agree; with a link sometimes, you want inheritance. Sometimes you want to stop inheritance and want a link. That's the extra bit people want.
Alex Hopmann: On the proposals around use cases, my concern is simple use cases. A calculator is simple, but more sophisticated things with DHTML and more complex things are what you need to demonstrate in an interoperable way. Use cases don't help there.

Mark Birbeck: We do have the specs for CSS etc. but they smack of a world with a monolithic browser controlling the entire environment, not for how it works with modular software. If we are happy to wait for Mozilla to implement MathML and then SVG and then XForms, OK. But people want MathML now. People want to incorporate it now. The browser doesn't provide the means to hook these things in. CSS is defined but we don't say how a module knows it is now green. Are there CSS events? A dynamic InfoSet module?

* General open questions

TV Raman: The cynical thing is that we are creating open tags without close tags and an ill-formed web. We had two discussions. What did we conclude?
Dean Jackson: I am willing for someone to stand up and suggest a conclusion.
Philip Hoschka: I would recommend a straw poll on priorities on work items.
Dean Jackson: A work item?
Philip Hoschka: XHTML+SVG+SMIL? An incubator? MIME type for markup?
Leigh Klotz: Note that on XHTML+SVG+SMIL the only communication with the server would be name-value pairs.

Suresh Kittori: Would the complexity rise or fall when you combine documents, or keep them separate?
Jon Ferraiolo: So the minimal possible to meet the requirements?
Suresh Kittori: See what we are gaining.
TV Raman: We've had the broad brush conversation, which set of markup languages, what VM/dynamic browser. Identifying those as work items won't move us forward. Let's identify the specific items and use those to build things let people move forward. Then let a thousand flowers bloom.

Chris Lilley: The relative turnover on hardware in mobile phones is an advantage that they can ship it, and ship something else six months later, and they want users. The trouble is a specialized browser will not get used.

Suresh Kittori: That's the old idea of profiles. We need a specification for the profile. Chris Lilley: You need test cases. The mobile profile really does exactly what they agree to.

Daniel Austin: If we go down this path of specific profiles, we will wind up with an addition to the ad hoc solutions. And we have a Note for these already (XHTML+MathML?). Are we going to proliferate the number of ad hoc solutions?

Mark Verstaen: The question is not will there be a profile, but will they the W3C have a XHTML+SVG profile? It will be shipping regardless.
TV Raman: If it's shipping in October, does the W3C need to? Chris Lilley: Vodaphone has four tiers of phones. The top three will ship with SVG and XHTML in October. We don't want "Select Vodaphone Profile."

Rich Schwarzfegger: Do the authoring tool up front and put it in your plan.
Jon Ferraiolo: There are authoring tool vendors in the room. What percentage of HTML is authored by hand? You can do markup for flowing text and it works OK but more visual stuff...as in the mobile space, you need tool involvement.
Rich Schwarzfegger: Why can't I just draw this? How do I pull it all in together? How do I make that easy?
Mark Verstaen: There are tools, drag and drop re-use, creation, etc. You need to specify the profile today (Nokia, Sharp, etc.) The way that bitmap fonts is not the same, focus across languages is not the same. We solved this problem in my company and can make money, but we don't think it's the right way.

* Profile Work Item

Dean Jackson: (writes) "Develop a specification that combines "profiles" of W3C Technologies, primarily focused at the mobile market space with a conformance test suite." I've not added conformance levels (Tiny, Basic, etc.)

Dean Jackson: Show of hands for Good Idea and Willing to Participate?
Robin Berjon: And opposed?
TV Raman: And how about XHTML + SVG + XForms?
Steve Zilles: If you form a group, the group should decide.
TV Raman: Let's solve the problems that enable these.
Dean Jackson: The group can decide once created.
Tantek Çelik: The use case is not acronyms.

Jon Ferraiolo: Let's go to the second one first:

* Incubator

Dean Jackson: (writes) Charter a (incubator) group to address:

Jon Ferraiolo: Two groups in parallel. So what Steve Zilles suggested...
TV Raman: If there are two groups, the short term has no guarantee to produce something compatible with long term.
Joshua Randall: You don't know the MIME type for XHTML+SVG, but let's stay away from specific mobile problems and solve generic compound document issues generically.

Alex Hopmann: How open-ended it is makes a difference for me. The mobile guys say that the specs are there but they need details about how to hook them together. You didn't mention ECMAScript or DOM so you're talking about the content space.
Dean Jackson: Yes.
Alex Hopmann: And add CSS.

Mark Birbeck: I think we should narrow this first task and not make the web applications work depend on it. We are requested to solve a specific problem of October in the mobile space. Just say there is an XHTML+SVG MIME type with a long name: application/xml+svg+xhtml, define a Schema that mixes them, and ship it. We don't pretend that it feeds into web applications, and separate the issue.

Robin Berjon: It's not just document -- SVG Tiny supports MicroDOM. Right now mobile stuff is entertainment. With more DOM and more information I would spend more money. It should be a strict profile, with exact user agent specifications.

Jon Ferraiolo: Yes, Suresh, can you list the companies who standardized the MicroDOM: Nokia, Sony Ericsson, Sun, IBM, etc. There is a large area of interest in scripting on mobile devices from big players. On the MIME question: Vodaphone is assuming that there is an outermost document type, .HTML or .SVG. You don't need a new document type. HTML Object or SVG foreignObject. But Vodaphone doesn't do the SVG foreignObject, just standalone SVG.
Steven Pemberton: So why do we need a spec?
Jon Ferraiolo: Vodaphone has a 25-point list they want to give to the W3C.
Mark Birbeck: Is the object tag the only way? How do you get an A inside SVG?
Jon Ferraiolo: If you want to see the the SVG document you click on it.
TV Raman: IF you look at the two extremes, for October, an XHTML+SVG thing that says how to combine, MIME type, syntax, Schemas, that doesn't need a WG. That is a W3C Note. Especially for October. But ensure that what it submits is an XML Instance not a name-value pair. That will give you longevity. Let's not do the 1994 kludge of name-value pairs.
Tantek Çelik: A quote: "What not to email. Email is safe unless it contains programs. Data and documents are fine. If you send me a program I will not read it." Tim Berners-Lee. Now, note that at the highest levels of the W3C the difference is acknowledged.
Robin Berjon: Nobody said there was not a distinction.
Tantek Çelik: Steve did.
Joshua Randall: The WD for August 2002 for XHTML+SVG+MathML. Isn't it already it?
Jon Ferraiolo: It is just the syntax. Chris Lilley: No, that is the horrible but necessary DTD modularization validates. It proves that DTD modularization works. It does not give you a working document.
Daniel Austin: It works on the screen. Chris Lilley: ...

Mark Birbeck: I see -- Masayasu asks who gets the event when you click; SVG or XHTML.

Unidentified Speaker: Let's try to get a conclusion here.

TV Raman: Jon, the problem is that you wanted by October is not simple any more. When you add SMIL you need to solve it again. You can get a W3C note by October though.
Jon Ferraiolo: A clarification. The Vodaphone thing is locked; they do not want the W3C to take it over; they want it taken over by a standards organization going forward. There is no imperative on the W3C to do a profile. But a following Spring2005 thing could take on low-hanging fruit.
TV Raman: Is it a six month or 12 month deadline? In 18 months we can do the right thing.

Steve Zilles: A third question: If there is to be a profile, who thinks it should be done in the W3C?
Dean Jackson: 19 Elsewhere? 0.
TV Raman: Attach a timeline.
Dean Jackson: ASAP? 21? Ad not ASAP? 0?

Dean Jackson: Based on that feedback of a majority, I believe that the W3C could take the next step to propose a charter and let the membership and public comment.

Suresh Kittori: I want the W3C to ensure that OMA and 3GPP endorse it. Chris Lilley: I agree and we have relationship with 3GPP and are building with OMA.
TV Raman: Do these need to be working groups or just notes?
Dean Jackson: Thank you very much Raman; good feedback.

** Charter a (incubator?) group to address:

Dean Jackson: At W3C? 23? Not at W3C? 2.
Dean Jackson: ASAP? 23? Not ASAP 2.

** Ian's proposed question Develop declarative extension to HTML and

CSS and imperative extensions to DOM, to address medium level Web Application requirements, as opposed to sophisticated, fully-fledged OS-level application APIs. Chris Lilley: Is this HTML and not XHTML?

Ian Hixson: Both HTML 4 and XHTML 1 and any level of CSS.

Dean Jackson: We've just voted on a group to examine use cases and this sounds like a use case.
Tantek Çelik: You haven't asked good enough questions for at least half the room.
Alex Hopmann: There are about 46 people in the room and about half of them didn't vote. I think that's not an overwhelming interest.
Robin Berjon: That's a pretty good vote for a standards organization.
Alex Hopmann: Of a two day workshop?
Jon Ferraiolo: Relative to the binary workshop?
Robin Berjon: In the binary workshop it was 30% or interest, and now we have an active WG. This sounds like a fairly good commitment and fairly overwhelming interest. Chris Lilley: The formal commitment can come only from AC Reps.

* Minutes

Chris Lilley: The IRC channel is down because of DHCP.

Dean Jackson: Leigh has taken minutes. Leigh's minutes are going to be the official ones. How should we validate that the minutes are correct?

Steven Pemberton: As long as they are posted as draft, then it's fine and after a week they are public.

** Straw Poll

Dean Jackson: Who does not want Leigh to post the draft minutes to the public list and then declare them final one week later? No objections.

Action 2004-06-2.1: Leigh to post draft minutes to the public mailing list.

Alex Hopmann: (leaves)

Action 2004-06-2.2: Dean to finalize minutes one week after workshop.

* Future Events

Kelvin Lawrence: At the 50,000 ft level, I think there is a danger we can get fixated on what we can do as technical guys who can write spec. We can pick some MIME types, but we should be talking about industry interoperability events to get people together.

* Processing Model

Daniel Austin: We should properly divide up our problems with the W3C Processing Model group. We don't want them to get too far down and ambush them. Let's make sure this activity is well advised of what we intend to do.

* Last topic

** Ian's proposed question

Dean Jackson: For XHTML and HTML, and every DOM level, who believes "Develop declarative extension to HTML and CSS and imperative extensions to DOM, to address medium level Web Application requirements, as opposed to sophisticated, fully-fledged OS-level application APIs."

Dean Jackson: For 8, against 11.
Kelvin Lawrence: Example?
Ian Hixson: The Opera Web Forms 2 proposal. One example would be to add a required attribute to the input element.
Tantek Çelik: This proposal mixes a lot of things that people want and don't want.

Dean Jackson: For XHTML and HTML, and every DOM level, who believes "Develop declarative extension to HTML and CSS and to address medium level Web Application requirements, as opposed to sophisticated, fully-fledged OS-level application APIs."

TV Raman: What is appalling about this workshop is that we had 100 people in the room six years ago that HTML was dead and we started XHTML. If we ask again this again today, what will we be asking six years from now?

David Baron: Conflict means normatively disagree.

Dean Jackson: For XHTML and HTML, and every DOM level, who believes "Develop declarative extension to HTML and CSS and to address medium level Web Application requirements, as opposed to sophisticated, fully-fledged OS-level application APIs."

Dean Jackson: 8 for, 14 against.

* Meeting Ends

Dean Jackson: Thank you to Adobe for providing the room and food. Chris Lilley: Thanks to Dean Jackson for doing a great job.
Dean Jackson: I will be bugging you to get the slides. I will send one more spam when the meetings are complete.