W3C Workshop on Web Applications and Compound Documents (Day 1) Jun 1, 2004

* Present

* Agenda

* Welcome and Introduction

Dean Jackson (W3C): Welcome. See the agenda and logistics on the workshop page. What is the purpose of this workshop? The position papers show a broad range of ideas. The W3C team and I have organized this workshop to answer two questions: Is there room for standardization in this area, and what is the scope?
Dean Jackson (W3C): Introducing Jon Ferraiolo, co-chair. Philip Hoschka W3C Interaction Domain Leader. The position papers on compound documents and web applications overlapped, so we grouped presentations by industry or association, or area such as XForms or SVG. If you do not want to present, please let me know; it is not required.

Dean Jackson (W3C): This is a public meeting, so all information, including minutes and list of attendees will be made public. There will be a log of the IRC channel irc://irc.w3.org:6665/#workshop made available.

* Bert Bos

Bert Bos (W3C): Nearly 10 years ago, HTML was in danger. Extensions for layout made HTML less useful, proprietary extensions, etc. so we created stylesheets. CSS is now being taken up, but HTML is in danger again. JavaScript is the worst invention ever. At first we though we could replace JavaScript with style sheets (rollovers, hover, etc.) and Java for applications, but Java is not so great for simple programs.

Bert Bos (W3C): So, perhaps we need a scripting language or two for the 80%, with the logic separate from the UI so that programs are portable, device independent, accessible, maintainable, re-usable...right from the start. Let's use the knowledge of the web to design something clean that will last for a long time. In my mind, separating the program from the logic is the most important thing, just as we did for HTML, separating the style from the content.

Bert Bos (W3C): Imagine we could start from scratch, leave the difficult 20% to Java, take two years to define our language, and two more years for version 2. (Shows diagram and simulation of three components: UI, Webapp (comprising UI and Logic), and then the Web. That is what we hope to achieve.

Bert Bos (W3C): Imagine and easy high-level interpreted programming language (something like Ruby?), and a 2-way pipe to an easy high-level declarative UI language (something like Gist?). View source for client side. This is perhaps a simple 80% solution.

Bert Bos (W3C): We need to work out the details: UI objects, built-in libraries, security levels, safe local storage, packaging and signing, the MIME type...

Bert Bos (W3C): I will update the slides on line.

John Boyer (PureEdge Solutions): I notice a similarity with what the XForms Working Group has put together. Have you looked at XForms? Bert: Yes, I am not sure yet of the role of XForms. IT could be part of the user interface. My thoughts are still that XForms are good for forms, but not for applications that I have in mind. Fields, yes, but for games or editors, no. XForms is more for as HTML is used. There might be a place.

* Mark Birbeck, x-port.net

Mark Birbeck (x-port.net): I characterize Web Applications that those that use the architecture and infrastructure of the Internet. Using HTTP and distribution. It's not a client-side app, it could be server side. It could be desktop. It uses the light-weight features of the Internet, distributing and application as markup. Here we see XForms being used for my slideshow; I would call it a web application. It is all declarative, and the applications are done using HTTP and file:.

Mark Birbeck (x-port.net): I am interested in this area because we had a content management system and wanted to move content from server to server, and wanted to migrate tasks. This opens up the possibility of intelligent agents that can move. I think this is quite profound. The browser, as well, is just another web application.

Mark Birbeck (x-port.net): Generally for mixed-namespace documents, you place a controller at some point in the tree, and this week we say we will resolve it. I think that paradigm is wrong and the web browser is just one application and this is not the correct paradigm for apps.

Mark Birbeck (x-port.net): For example, here is my web browser, and a to-do list at the bottom, built in to the application as a footer in Internet Explorer, running as XForms inside the browser. Unlike what Bert was saying, it is the XForms model that is powerful here. I think this is suitable for desktop applications.

Mark Birbeck (x-port.net): One of the important areas to address is changing what we see as a renderer: as Bert was saying, we should break off rendering. I think we need two DOM trees, one for the application, and then push the rendering off to the last minute. We could usefully standardize rendering. We could have a system tray URL, toolbar, search bar, etc. For example, here is an XForms search bar. The search results bar here uses XForms. There is also a voice rendering going on. We have targeted the voice rendering using the same XForms markup. All of that work needs to be done to break out the rendering into a separate area.

Mark Birbeck (x-port.net): We need to augment the InfoSet to enable serialization (save and resume, agents). Instead of CSS for voice, rendering and color, etc, we should put those as attributes/elements on the InfoSet so that they are in the DOM, layering CSS on that as a selection language for matching those nodes. At the moment, we are taking too long to produce specifications because things like CSS are monolithic and require the authors to be experts in too many areas. So, a plea for pushing as much as possible on the InfoSet. For example, in XForms, you can say that a node is relevant or readonly using XPath expressions. So we could do the same with red, blue, etc. So we can use these specs to create others. Thank you.

Steven Pemberton (W3C/CWI): My only comment is that I think that the browser issue is orthogonal.
Mark Birbeck (x-port.net): I agree; how to we make a bridge between the future that we want and the present. We treat the browser a renderer, and Adobe SVG plugin a renderer, and Microsoft Agent.

Philip Hoschka (W3C Interaction Domain Leader): I read you paper on a standards-based Virtual Machine. Could you comment on that?
Mark Birbeck (x-port.net): That is the final step of everything I was saying. If you start at the ground and say we have the DOM and layer rules on it, and say that if this node changes that node becomes 5 more than the other node, add validation, add Schema awareness, add selection languages like XPath, then that is the basic set of features that our virtual machine must support. We can move our applications from one device to another using declarative markup.

* Matt May, W3C

Matt May (W3C): A confession: I broke the web. I broke accessibility and compatibility. I started working for HomeGrocer.com and Webvan. We had to create a UI. In 1997-1999, the browsers were limited. We, and everyone else, pushed the envelope of HTML. We invented these things, and took a document format and stripped it of its semantic value, eliminated what it was capable of doing, and turned it into a web application platform. We added cookies, center, font tags, document.write, etc. The ultimate product was an inferior platform for applications.

Matt May (W3C): Real life problems:

In Accessibility, much of the work has been trying to build in these things, as with font tags and so so, we have no idea what you were trying to say. This problem is a second order effect of web authors forgetting that there were any semantics. For assistive technology, for example, the 50 ways to do anything in JavaScript make it impossible to figure anything out.

Matt May (W3C): I have taken a look at what most script does:

Matt May (W3C): What of these things can't be done declaratively? Look at models such as XForms. The validation stuff is already there. Also SVG and XUL/RBL.

Matt May (W3C): What do we need for accessibility? We need one package. A fragmented approach is inaccessible. Assistive technology developers have limited cycles. Assistive technology developers will pick one, and that will the only one deemed accessible.

Dean Jackson (W3C): In WAI, we have approaches progressive to radical:

We want to get as close to one model as possible.

** Questions

Rich Schwarzfegger, IBM: A lot of what we are doing for XHTML 2 can be applied to XHTML 1.1. We have fundamental problems to address. When we added DOM 2, we made all of the elements active in the DOM. We can't give any of those elements focus. If you are a blind user, there is no way to go to an element in the document, and people use forms and ids. Now using namespaces, you can extend div and span elements and give them focus. Can we change the specification to give elements focus? We did a UI widget built out of divs and spans, a checkbox. For XHTML Events, etc. I would like to address that this week.

David Baron: Some of these accessibility problems are for screen readers interacting with markup (semantic and non-semantic) designed for visual presentation. I am curious how much you have looked at implementations designed from the beginning to be a speech implementation, where you can deal with semantic markup without going through a visual presentation..

Matt May (W3C): I have to defer to others, but the key is in a lot of cases, the browser's role is to expose the DOM or object model to the user. So really whether it is a visual representation or not, it is a bug to the users of the screen reader. They want to extract the original semantics of the document. For Web Applications, those semantics aren't as good. In the long term, it is better to create a set of semantics to render the application as intended.

* Vincent Quint, Irene Vatton, INRIA

Vincent Quint (INRIA): I want to address one issue, with answers based on our experience with Amaya.

** Nesting

Vincent Quint (INRIA): Amaya has support mixing multiple levels of embedded elements. Examples: XHTML SVG MathML, XHTML SVG XHTML MathML.

** Structure

Vincent Quint (INRIA): A single DOM tree containing all embedded elements makes editing easier. A single application handles all XML vocabularies. Wrappers such as object or foreignObject are hidden to the user. Are wrappers necessary? XHTML+MathML does not use wrappers. Common parts are shared in the processor and only the language specificities are handled separately. Example: Here is a real-life scientific paper. There are a number of different objects in MathML mixed in the text, in each paragraph. It would be difficult to edit all of these separately. Integrating into a single tree makes it easy to manipulate such as document.

** Editing Modes

Vincent Quint (INRIA): Different modes for editing different XML vocabularies:

Different modes to manipulate XML at different levels:

** Multiple views

Different modes are accessed through different views:

** Questions:

Rich Schwarzfegger (IBM): We need to have a WG define what user agents should do, and one for what authoring agents should do, not just markup.

Peter Stark (Sony Ericsson): In an authoring tool, how does the author know how the elements can be combined?
Vincent Quint (INRIA): In this tool only 4 languages are supported. Every language is available at any time anywhere.

* Discussion

Jon Ferraiolo (Adobe): Let's bring the speakers up.

Chris Lilley (W3C): Most of these applications aren't just locally; there are intranets, and trust scenarios. When you move to script, you get trust and limitation issues, security holes, etc. Security issue and trust boundaries?

Bert Bos (W3C): I put something in the position paper. One part is signing the program who. So you need a packaging format and XML Signature. Another part is you need standard communication libraries so you can have control over what is sent back and forth. I don't know the details. Matt: It's already happened. Having a model that is actually convenient to communicate over, using POST or Queries isn't convenient. A web services model would be beneficial.
Mark Birbeck (x-port.net): There are two parts to the question: What are the issues in security, and I want to use script, how do I make it secure? The second part is like how do you secure your home? I think that script is used to implement foundations, just as Java/C++/C#, but I think we don't need script. The advantage of a declarative model is reasoning. We have semantic web overload from New York, but you can take a web applications and reason which servers to run the various parts on to avoid holes. The script itself is out of this discussion.

Håkon Lie (Opera): Bert started his presentation by saying he joined W3C to save HTML. How do you save something? How do you save a village? An endangered species? Do we save it by freezing it? Or by doing something totally different? Evolve it? Do we want a revolution or an evolution? I have my own views after lunch.
Jon Ferraiolo (Adobe): Down the line.
Mark Birbeck (x-port.net): I've always been for revolution. This conference is about web applications, not about saving monolithic browsers. I want to build applications. I've been programming for 23 years. Everything I sit down, I worry if I have to get out a C++ or Java compiler. I want a simple application distribution mechanism. I want to swap my TO Do list for an Expense form. Our starting point is not saving HTML.
Bert Bos (W3C): No general but, in this case, a revolution. Keep HTML, it is getting better, evolve it, so we don't lose what we can. But make a revolution. This is the time to do it. We can start thinking about an application revolution.
Vincent Quint (INRIA): You can dream of revolution; just defining things like you would like them to be and starting from scratch. But you can't break everything; it is not possible. We need to evolve and introduce new features one after the other to integrate them into the base. Let's define nice new features but make sure they integrate into the existing base.
Matt May (W3C): I think that both sides are evolution. The root for evolution is evolve; the root for revolution is revolt. We are not revolting against HTML; we are revolting against people who are using font and center. Get CSS into the fold in HTML document creation. The long scale is moving into an application model.
Jon Ferraiolo (Adobe): Great question!

Steven Pemberton (W3C/CWI): Are web applications and compound documents related subjects? Does it matter what the definition of compound documents is?
Bert Bos (W3C): They are different; In the case of compound documents, it is important to to know. We need to distinguish between documents like Vincent showed where everything is in one file vs links. They are not the same thing. An application can be compound.
Vincent Quint (INRIA): Just a word: what I have shown is a single document but it doesn't need to be a single file. That said, I agree with Bert. I decided not to put web applications in my talk. Compound documents themselves are an important unsolved issue. We have to develop new techniques. We can address the two separately.
Matt May (W3C): Compound documents are the format of a payload to the web applications framework. You can arrive at mostly the same effect with pointing.
Mark Birbeck (x-port.net): I agree. The point is that web applications are a special case of compound documents. There are special issues around compound documents. There are some issues to pry apart: schemas for editing vs schemas for running. In XForms you can put an SVG document in a label. Another distinction is a language for editing vs for specifying. Do we want to send 20 SVG rectangles or a bar chart?
TV Raman (IBM): This is an observation with respect to evolution or revolting. Let's step back. What HTML was an what it became in the late 90's? HTML got lost in the gorp of document.write. XHTML 2 is recovering its roots. The experimentation with script in the late 90's was discovering what we needed: validation, interaction effects. Now it's time to codify those and take HTML back to its roots. I appreciate Bert's saving HTML but we need to take it back to its roots.
Matt May (W3C): I agree. I think that what we have right now, what made HTML successful, was that it satisfied the good-enough technology test. People have taken HTML 4 as the lingua franca. What we need to get over this, and the barrier to XHTML 1.1, is part architectural and part social. People need to see that there is enough value. That's a revolution. We need the critical mass going forward for XForms, XHTML 2, SVG. That is how we move past this unattractive part of the late 90's.
Mark Birbeck (x-port.net): I agree but there are two worlds: applications and documents that link. The documents look cleverer but are not applications; for example they cannot validate your data. There is nothing wrong with HTML taking its role. But look at Microsoft Money or Quickbooks; they have embedded within them a browser-rendering technology. At the end of the day, there is loads of C++ code at the back and the renderer at the front. Bert is right: we need to address the back bit now. There are two worlds.
Matt May (W3C): I see that as a continuum. Add search to an HTML; add send us email address. Is that an application? It's that transactive model. I'm running an online grocery; i have 30,000 items in a table. I don't care about searchability; you have to search through the data itself (semantic web). When you get to that stage, you see that HTML is not good enough technology any more. We need to create a cross-platform web-oriented application platform with some on the client and some on the server, and make it all accessible.

* Break (30 minutes)

* Peter Stark, Sony Ericsson, Web standards in mobile phones today

Peter Stark (Sony Ericsson): XHTML/CSS, SVG, and SMIL(MMS). Four years ago WML was relevant, but today it is XHTML. We are also using SVG for simple animation. We use SMIL for multi-media messages. We use several web standards for different applications. SVG is a dedicated player, SMIL for MMS client, and XHTML for browser. They are not used together.
Peter Stark (Sony Ericsson): Camera phones an new graphics-based user interfaces raise the bar for mobile web applications

* Wanted: A language profile that ingrates XHTML Basic SVG Tiny and SMIL Basic

** Questions

Dan Zucker (ACCESS): You propose a mobile profile, but phones get more powerful. Also, vendors want to differentiate.
Peter Stark (Sony Ericsson): Profiles drive the industry forward. Vodafone for example, can drive by requiring SVG 1.1 and then 1.2 next year. So it's good to have well-defined profiles.
TV Raman (IBM): We should be careful about saying profiles are good. The pace at which the mobile industry moves, if we do profiles based on today's devices, what happens to the content we tie to today's devices?
Peter Stark (Sony Ericsson): The problem is there are no profile today and you get interoperability problems.
Chris Lilley (W3C): I agree that profiles are needed; but just saying what tags isn't sufficient. Integration with context (where events flow, etc) and conformance requirements are necessary for authoring tools to work. Otherwise the authoring tool will ask if you want to export to a Sony Ericsson or Nokia, etc. We need a CR process for conformance profiles and then implementation of the platform can provide a basis for vendor differentiation on top of that platform.
Daniel Austin (Sun Microsystems): You provide a specific solution to a specific problem on a specific device. Next year, it will not be useful, just like WML. What we need is a general solution to how do we mix and match.
Peter Stark (Sony Ericsson): I agree first we must solve the problem of how we mix and match, but you need to have profiles that work. Sometime we exaggerate the speed at which things move. XHTML Basic was defined four years ago and it's not until now that you see it across phones.
Glen Gerston (Ideaburst): You put XHTML Basic, SVG Tiny, etc. Handheld devices get faster and it takes a year. Is there a reason we are always dumbing down these specifications? Why don't we look at interoperability between languages and namespaces?
Peter Stark (Sony Ericsson): I think there has to be minimal requirements. Also, for some things the evolution is not as fast as we would like. Next year we may see SVG Tiny on devices.
Jon Ferraiolo (Adobe): A lot of these things are not mutually exclusive; extensible architecture and other profiles are possible.
Chris Lilley (W3C): In terms of the minimal requirements: DOM Level 2 and XML parser, but eventually the desktops will catch up to that level.

* Dynamic Web Applications Authoring, Deploying and Consuming Mixed-Namespace XML, TV Raman IBM

TV Raman (IBM): You can't separate these two issues.

** Outline

** Characteristics

TV Raman (IBM): The web browser is a means to an end. A web application is characterized by these points:

** Prerequisites

TV Raman (IBM): In HTML, we factored out presentation. In this go around, we need to factor out interaction, which is eventing.

TV Raman (IBM): Whether I am using a mouse, a cell phone, or a speech UI, the app model is constant. The UI logic and look and feel change. When I was at Adobe, I would ask for people to take the head off the app and give me the app. When you bolt different heads on apps, you see that web apps and web services are the same.

** Web Services and Applications

Services|Applications Publish Model|Publish Model Machine UI|Human UI Callable|Callable Abstraction|Aggregation |---Eventing--| Coarse-Grained|Fine-Grained TV:What does it take to turn your pizza store web site into a web service? Factor our the model to produce an XML document,

** Building on what we have

TV Raman (IBM): Web Applications As compound documents. Apps deployed across the network, deployed independently of server. At each point in the network you want something interoperability. For better or worse (mostly better) we have XML and angle brackets. So your compound is a means to that end.

** Versatile Deployment

TV Raman (IBM): Consistent eventing model is essential

TV Raman (IBM): See my position paper for more points.

** W3C Building blocks

TV Raman (IBM): At the bottom of the stack we have namespace, protocol, HTTP.
TV Raman (IBM): Next up we have the XHTML container and the XML DOM at runtime.
TV Raman (IBM): Then we have XHTML Content in the container styled with CSS.
TV Raman (IBM): Then we have Vectors in SVG, Voice in Voice XML, Metadata in RDF Triples, and Timing in SMIL.
TV Raman (IBM): Above that we have meta things, XSL Transform, XQuery finding, XSchema types, XPath access.
TV Raman (IBM): Finally, at the top we have the XForms model and XML Events for eventing.

TV Raman (IBM): Unfortunately, this model comes loose at the seams. We haven't clearly defined the eventing or styling semantics for these languages. So when we mix and match them, it breaks. The xhtml:a element has application semantics. The xhtml:b element has semantics that gets styled as bold.

* Authoring Mixed-Namespace XML

TV Raman (IBM): See my slides

* Conclusion: Web Ready to Take Off (Again)

TV Raman (IBM): We have stagnated in the last 5 years and if you want the web to take off you need to take it to the next level.

Hermann ?: We are looking at Struts and implementing applications. When I hear about declarative compound documents getting smarter, is that it is very difficult to interface the imperative language (Java or C#) into the markup that gets smarter. In Struts and Java Server Faces, if I make a mistake when typing, it may cost me 30 or 40 minutes of looking around because there is no way to interface the Java class with the actual element. This may be part of the larger problem. I am looking forward to declarative markup, but I am having trouble debugging with no tools.

TV Raman (IBM): There are two thoughts: declarative vs. procedural, and your pain. You are having a hard time debugging things on the server. The model on the client has not evolved. You are evolving rich models on the server and then doing printf of HTML and JavaScript. You are writing code that generates code that generates code and that's hard to debug. The client model should be richer and match what is on the server and it is easier to debug.

Daniel Austin (Sun Microsystems): You started talking about web applications but you addressed compound document problems. Are there web application problems that don't match compound document?
TV Raman (IBM): Compound documents are a means to an end. They won't let me implement a car race game or the next version of Doom, but I don't care and I don't want to.

* Jon Ferraiolo, Adobe

** Recommendations

Leigh Klotz (Xerox): Could you say something about XForms?
Steven Pemberton (W3C/CWI): Their paper does.
Jon Ferraiolo (Adobe): It seems a good basis theoretically for W3C applications. It is a tough question for Adobe, as we don't have any XForms products shipping at this time.
Steven Pemberton (W3C/CWI): Your PDF viewer is now called Adobe Viewer. Are you going to be merging the SVG Viewer and the Adobe Viewer?
Jon Ferraiolo (Adobe): I can't really comment about future product plans. There are forces in play that could make Adobe move toward increased support of W3C standards in our ubiquitous viewing products.

* Web Applications and Compound Documents, Vincent Hardy, Sun Microsystems

** Technology silos

Vincent Hardy (Sun Microsystems): SVG, XHTML, SMIL, XForms...they are silos. SVG is a wonderful technology for graphics, etc. But documents and applications need XMLn. We do solutions redundantly: in SMIL, and in SVG. We need one solution for one problem. It would be nice to use a little of each. What you get by combining is a multiplication factor. We think that we should start working on this. Focus on what application authors want to do rather than any particular technology area. Combining markup delivers a lot of value.

** Combining existing features

Feature|Existing Solutions Document and Page Layout|SMIL, CSS Box, XSL FO Resolution Independence|CSS and SVG Multi-media integration|SMIL Animation|SMIL and SVG UI Components|XForms, RCC Extensibility|XBL, RCC

Vincent Hardy (Sun Microsystems): There is no agreement on how to combine them: mixed namespaces, object, foreignObject. But we are not starting from scratch.

** Some of the challenges

Vincent Hardy (Sun Microsystems): Limit integration points. When you load your document and change it through the DOM API you get new difficult problems in validity. In the SVG case we found a domain-specific API was very useful.

** Conclusion

** Questions:

Chris Lilley (W3C): Could you comment on Sun's XML Processing pipeline?

Vincent Hardy (Sun Microsystems): Unfortunately, no.

Mark Birbeck (x-port.net): This is what lead me to thinking we have to go up a level. There will be new languages. Nobody seems to like the answer to the question "When will Internet Explorer support SVG? XForms?" We have to move to a level to where we can combine them. The specifications you list give three ways to load documents. The specs take years and are too big. We have to break them down. I don't think that we can solve the problem if we look at it as XML to the power of N.
Vincent Hardy (Sun Microsystems): With smaller profiles and mobile, the implementation complexity goes down. We have more implementations of SVG Tiny 1.1 than we did of SVG 1.0 full. It's basic math; the complexity; it's for domain-specific platforms, but we see results. Complexity goes up, the implementation cost goes up, and the testability goes down. The drive is mobile -- their incentive to combine markup is higher.

* Discussion

Dean Jackson (W3C): Do mobile vendors who didn't present want to add something here?

Suresh Chittori: My question is about time to market from defining a spec and supporting it market. The spec was defined in January of last year and we don't have a good number of products. And how do we define profiles? We should start with common requirements and use cases medium term.

Vincent Hardy (Sun Microsystems): We can talk about how we go about adding features and making sure they are testable. In practice, there is still room for improvement. For SVG, if you want to add a feature you had to come up with the tests. Adding tests early helps.

TV Raman (IBM): The delay is not because the work is futuristics, but because haste makes waste. WG's decide they have to do it quickly, take shortcuts, and then the constraints become irrelevant. In 1992-1993 you could write a web browser in two pages of Perl. Ten years later we have a more sophisticated stack that is large and monolithic: XPath, XForms, XML Schema, are all big and complex, but they are designed to be modular. If we get this right, at the end of the day, an XML browser will be easier to write than an HTML Browser of 1999.
Jon Ferraiolo (Adobe): It's hard to speed up certain processes without making it wasteful. In general, it is time for the W3C to exert more leadership in leading the industry, and having an architectural vision, would tend to increase the focus to standards for market.

Dean Jackson (W3C): I like that question so we'll come back.

Håkon Lie (Opera) I'd like to discuss namespaces. Raman put up boxes on the screen for specs in the years past. Lots of them are meant to be combined with namespaces. But namespaces have problems -- we have implemented them in Opera, but we are still faced with what to do about namespaces we don't know. Micah pointed out that 80% of the issues have to do with Namespaces. Then there is Tantek's proposal for one namespace for W3C. Are namespaces the solution here?

Vincent Hardy (Sun Microsystems): It's is one technique, but it doesn't solve the questions of model and intent. If you mix markup, you may embed a 3D markup in SVG as metadata, or you may want to mix them up with the intent that both are rendered. XML Namespaces doesn't answer that. SVG represents a rendering tree, and XForms has a model element. The nodes represent different things; just because XML Namespaces can mix them doesn't answer the purpose or semantic issue, just the syntax.

Tantek Çelik (Microsoft): When I proposed a single namespace for document formats, it was not for all W3C work. The namespaces are the causes of the silos.
Jon Ferraiolo (Adobe): Pandora's box is open on namespaces. We can't turn back the clock. C++, for example uses namespaces, as does Java. There's no way to avoid it. We can complain about how difficult they are but we are stuck with them.
TV Raman (IBM): I agree. I put namespaces and HTTP at the bottom. Nobody throws stones at HTTP, but until 7 or 8 years ago, they did. Let's talk about eventing and styling, not casting stones at namespaces.

Charles Ying (Openwave): Content developers should be involved early on in the spec process. We are still trying to see mass adoption of SVG in mobile. We are confident but we need to see content developers involved sooner.
Steven Pemberton (W3C/CWI): Join the working group if you want early involvement.
Charles Ying (Openwave): Not Openwave, but Andrew Wallace or specific design firms.
Peter Stark (Sony Ericsson): Authoring tool vendors as well. You mentioned SVG -- we did a lot of work to get SVG into phones but there is no good tool for creating SVG Tiny documents. We have no good end-to-end solution.

Scott H: There are efforts going on in other bodies. Waiting too long is too looking. 3GP, etc.

Mark Verstaen (Beatware): There are good tools for mobile but W3C doesn't know about them.
Peter Stark (Sony Ericsson): There are a few tools but not many.
Mark Birbeck (x-port.net): Give them visibility.

Dean Jackson (W3C): Jon suggested that the W3C take a stronger leadership in developing specifications and said not to rush.

Jon Ferraiolo (Adobe): Work smart, so be efficient. That's what leadership is about; figuring out what is important and do it throughly, carefully, and as fast as you can. Say no to the things that are not important and prevent distractions, to bring increased interoperability to the web, which is the mission.

TV Raman (IBM): Leading the web to its full potential has stagnated because we focused on the web browser. We need to develop new viewers. The question about how to debug the HTML produced on the server is easier to answer if we untie our hands. Don't let the browser do the leading, let the W3C.

Steven Pemberton (W3C/CWI): The 5 years that Peter mentioned for a spec getting critical mass is reasonable. If you produce your spec in 2 years, you then have to get it implemented, get mindshare, and get it used. The same was true with HTML 4. We have to get used to it.

Vincent Hardy (Sun Microsystems): The cycle in mobile is faster than desktop. When people change phones you have new devices and new capabilities.
Peter Stark (Sony Ericsson): The capabilities of phones increase fast. It took several years to move away from WML to XHTML, and SVG took years.
Dean Jackson (W3C): We have been working with Vodaphone on the SVG group on a specification for their Vodaphone Live platform. The implementations follow quickly.

Bert Bos (W3C): I'd like to hear about profiles; we do them for mobile, how about for desktop. A collective profile, PNG, XHTML, etc. People said it was impossible, but it seems possible for mobile. Are we not pushing it enough? Is browser turnover too slow? Should we work on it?

Jon Ferraiolo (Adobe): One possible explanation is market dynamics; there are multiple vendors that need to make money on subscription services and there is pressure for interoperability and not proprietary desktop things. On the desktop we have Microsoft Intern Explorer, Adobe Reader, and Macromedia Flash...
Vincent Hardy (Sun Microsystems): It takes us back to complexity. The implementation costs are lower.
Peter Stark (Sony Ericsson): The industry has a few major companies such as Vodaphone, NTT DoCoMo, and T-Mobile to set requirements.

David Baron: Namespaces and componentization, devices-specific profiling. Ten years ago if someone had asked me to describe what is neat about the web, I would have said it was universal access to information. Today I'd still see it that way but it's also applications. I have trouble understanding the desire for device-specific profiling for document formats. What are the documents on the web supposed to be? Are these devices part of a proprietary system?
Vincent Hardy (Sun Microsystems): Personally, content authors will make decisions based on who can read content. In the short term, that is SVG Tiny.

TV Raman (IBM): We are confusing profiles and documents vs. what content you deploy on the web. The profile argument at the other extreme that deploying web content in a profile fragments the web like WML. At the same time, authors and implementors need to know what to do; content should be long lived and then address the content in devices in intermediate servers; that is more tractable.

Daniel Zucker: A key issue is that there are 3GPP, 3GPP2, and OMA in the mobile space for standards groups. To avoid fragmentation, now is the time for mobile phones to become a first-class communications device and it's time for the W3C to champion a unified mobile profile.

Mark Birbeck (x-port.net): I feel the standards process question is the most important one of the weekend. Technically, coordination, standards, and discussion and how to get the mechanism into place is important. Profiles say "I like your spec. I don't want to implement all of it as I have a specific problem." It's a subset. So, how do we address that? Maybe the specs should be structured in a different way to take subsets and make them interoperable. Five years is fair enough for a standard, but the process involves creating a standard markup and then analysis, requirements, systems analysis. The markup and syntax is secondary. Let's analyze it and get stuff out quicker in smaller units and draw on them more flexibly.

Daniel Austin (Sun Microsystems): I've been on 12 W3C Working Groups. It's difficult work. For six month timeframes as Peter said, is it worth going through effort to standardize that? Or should we focus on longer timeframes?

Alex Hopmann (Microsoft): There was a time when web browsers were on that timescale, but now we are paying for that now with security issues. Web Applications make the security orders of magnitude more problematic. I am frightened when I hear about cell phones with six month development cycles. I say this with all humility because my company's customers are going through this on PCs as well. Do we need to standardize this that quickly?

Peter Stark (Sony Ericsson): It's important for things like Vodaphone Live to have external standards to focus on; otherwise there will be SVG profiles for the vendors by themselves.

Jon Ferraiolo (Adobe): The devices get replaced but future devices should run the old standard.
TV Raman (IBM): XHTML browsers grew in complexity by adding a little at a time. Mismatched tags, blink, etc. The devices rev every six to twelve months. What changes? They get faster, more memory, more bandwidth but more slowly. The display and your fingers don't change. The quality of user experience changes; the content needs to be designed for the long term. It's a big monitor vs. a small display. The cell phone with a small display may not be a problem as there may be flat panels around for your cell phone to talk to. Don't dumb down the markup.

Glen Gerston (Ideaburst): The market factors that push development speed...who wants the device to be fully compliant with the SVG specification? With the 1.0 specification we have a lot of what we need with SVG 3 viewer from Adobe. It's not easy because there are no tools, but that needs a market. How do we accelerate those processes so people can see what can be done? W3C can promote the technology to developers. The cell phone market has a market filling a need. SVG can do this; for desktop, people haven't figured out what SVG can do.

Scott Hayman (Research in Motion): We profiled and modularized in the SVG WG. Everybody knew that the platform was limited. On the desktop, though, you can get implement just about anything, so you end up with a huge spec.

Jon Ferraiolo (Adobe): That brings us up to a 90 minute lunch break.

* Afternoon

* Opera Software and Mozilla Foundation

Håkon Lie (Opera): This is a joint presentation by Opera and Mozilla. The Lemmings game you see here is done in HTML and JavaScript. It is scary inside but shows what can be done. It's not accessible, but we want to make it easier to do this kind of thing.

** Ian Hixson

Ian Hixson (Opera Software): My favorite topic is backwards compatibility. If we want to start over with SVG and so on, we have years of effort. Accessible is frankly not there, but we want a backwards-compatible solution that we can deploy with current or soon-to-be-released browser. Web applications already exist, Amazon.com and EBay.com for example. Documents are becoming interactive as well. But if you view SVG or XForms in today's browsers, you get just text, and nothing works. What we mean by backwards compatible is stuff that works in today's browsers.

Ian Hixson (Opera Software): The parts of CSS, PNG, etc. that are used are the ones implemented in Internet Explorer use. Flash ships and people use it; SVG ships and people don't use it. There are ways to things such as Dean Edward's "IE 7" project done using HTCs (Microsoft proprietary technology), JavaScript, etc., and has supported CSS in IE without binary downloads. Another reason to be backwards compatible is that authors already know HTML and JavaScript. In conclusion, a solution based on HTML is better than one that isn't.

** David Baron

David Baron: When I think about what the web is, it is a system for universal access to information and applications. Specifications should encourage access to all devices, and content should work with all devices. That is not necessarily easy. There are a lot of specifications coming out and making them all work is hard. There is a need to limit the number of documents coming out. But I think that is the wrong solution. Those are signs of a problem that there is too much web or too much (???). I don't like the idea of device-specific profiling. We do have existing mechanisms for separating content from presentation and there is sense in profiling on presentation but not on the content side.

** Håkon Lie

Håkon Lie (Opera) Those are the things we want to highlight. Over lunch, one person asked if Opera is no longer the rebel browser. In this context, we are more evolutionary than revolutionary. We could invent new formats; we did that with CSS. It is a long hard battle. We want to build on what is there and works already.

TV Raman (IBM): So you are saying you are tired?
Håkon Lie (Opera): We have some left but want to use it where it makes sense.

** Questions

Chris Lilley (W3C): You said that people use Flash because it ships with the OS, and people don't use SVG because it doesn't ship with the OS. That's true but 50% of IE 6 users upgraded to it rather than getting it with the OS. You also said the IE 7 is a download and useful but it's like something that can't be used. I think that it is incredibly shortsighted to say that when Longhorn ships; what are you going to do then? "Boldly shipping last year's browser?"

Ian Hixson (Opera Software): The IE 6 upgrade numbers we would need to see. The IE 7 is a single-line, not downloaded separately.
Alex Hopmann (Microsoft): It's not an install.

Daniel Austin (Sun Microsystems): There's something called CC/PP. Can we learn from why it has not been adopted for the heterogeneous device problem? I don't want to see us go down that

Other Unidentified Speaker: We don't want to create two webs.

Mark Birbeck (x-port.net): As Ian Hixson says there are web applications on the server, but we want to push that work onto the client and make the line more flexible. Showing what we can do today is not interesting. We want to address the problem of things we want to do but can't do today.a People on the SVG list ask about validation and synchronizing form controls.

Håkon Lie (Opera) We shouldn't throw out what we have; we're still here to work.

* Alex Hopmann, Microsoft

Alex Hopmann (Microsoft): I've been working on standards since 1993 and at Microsoft for about seven and a half years. In the development of IE and Outlook Web Access. Microsoft has been building rich client apps over the web since IE 4. It's been a big focus for us and we hear a lot of demand from customers. There are a couple of consistent things we hear. Capability, manageability, and security are big ones. Security more lately. Interoperability is also something we hear. We look for the biggest value for interoperability and for conflict with the other goals.

Alex Hopmann (Microsoft): For interoperability, we look at protocols and schemas, etc. Customers want to deliver these applications over the network and evolve them quickly. There is a continuum in documents and interactive content. Content is more useful 5-10 years from now. There is an activity to develop it. You want to preserve the essence for the future. Applications tend to have a different lifespan. While I will grant that there are applications still running today that were developed 30 years ago, but they have been tweaked. Certainly for the types of applications that people look at for web apps, we see the need for that agility. The popularity is for updates over management of installed applications. Those developers are always using platform enhancements.

** Longhorn

Alex Hopmann (Microsoft): We had a week-long conference on this, but a few key points:

I am on Avalon, which is the Presentation Pillar. (The Indigo Technology is the new services framework. Applications can seamlessly tie in to web services.) Avalon replaces GDI, GDI+, User, all that for drawing.

** XAML is part of Avalon

Alex Hopmann (Microsoft): XAML is a markup for specifying a tree of .NET objects. It does not get rid of imperative programming. Part of the application is 100% declarative, and part is written in my favorite language for the Common Language Runtime. It is flexible. It is designed around declarative form tying into accessibility and influences our class library. There is a button tag for the button widget. If you add a MyWidget class there is a MyWidget tag. It influences the design of the class libraries.

Alex Hopmann (Microsoft): We also do 3D graphics, advanced features such as bring-ins and alpha, ???, advanced text support, theming, accessibility, etc. a very broad platform.

** Internet Explorer

Alex Hopmann (Microsoft): The last key aspect is the app model; how do I get the bits to the client? It also involves hosting in the browser window or not. It's not a set of technology choices to run here or there. We are continuing to invest in IE. The reality is that the IE team has been very focused on security work. There is a new service pack coming out very soon, not whiz-bang new features.

** W3C

Alex Hopmann (Microsoft): We want to to focus on where we are going to be successful. Standards for APIs and Object Models are not going to be successful. That makes a fragile platform, causes security problems, and creates complexity. You could have a simple language, but when you give developers an imperative language, they can do Lemmings or build Outlook Web Access. We pushed the limits of the platform and it was fragile. It's very easy to break edge cases. If you give developers an imperative language they will push it. You also get interactions that cause complicated code paths that cause security problems, call order problems, timing issues, etc.

** Summary

Alex Hopmann (Microsoft): People should stay focused on declarative content in the W3C and develop long-lived formats. For example, the new CSS3 work is good and doesn't introduce new imperative complexities. Tie things together and build real apps with interoperable web services.

** Questions

Patrick Schmitz (Nirvana): I used to work for Microsoft but am now at Nirvana. You talked about sustaining work in Internet Explorer and what replaces it in Avalon?
Alex Hopmann (Microsoft): In Longhorn there is a separation between multiple rendering models, chrome, and user interface. Avalon can be hosted as well as Adobe Reader.
Patrick Schmitz (Nirvana): There's always been a separation there; MSHTML and IE were separate. The extensions for plugins were there.
Alex Hopmann (Microsoft): We don't have plans to replace the MSHTML module. It's tuned for rendering the bug-compatible web. We got IE4 to work with the top 1000 web sites. While we continue to explore new things for content formats. That will stay where it is at.
Patrick Schmitz (Nirvana): What about XHTML and SVG?
Alex Hopmann (Microsoft): We don't have any announcements to make but obviously you could build them.

Unidentified Speaker: You said the button map object and the class...I'm already doing that in Java. I think it would be of importance in the CLR, is there any type of effort to let them be known and connected at the CLR level? Some of this is borrowed from Don Box, where the expression level of conserved semantics would be higher. How does XAML connect the imperative C# with the representation?
Alex Hopmann (Microsoft): We experimented with approaches with XAML. It is an alternative way to write the constructors. It makes the source code easier to target. The patterns for reflection etc from CLR and dynamic properties with change notifications and eventing etc. The Windows eventing model and the .NET technology is a pattern that helps the runtime carry forward the declarative markup.

Håkon Lie (Opera) When are you going to submit XAML to W3C? And what about licensing on XML patents as you did with CSS?

Alex Hopmann (Microsoft): We don't plan to submit it at this time; it is a markup language for Windows, and W3C is for markup language across systems. We engage W3C for CSS and XHTML. I can't touch on legal issues because I am not a lawyer.

* Red Hat

Owen Taylor (Redhat): I have been working on desktops. The diversity is a bit like the web.

** Background

Owen Taylor (Redhat): For the "XForms" version, is "UI anything goes?" Every 3D game looks different and the user has to learn it. You have to separate the UI piece into three layers and separate the UI Structure and the Appearance. That distinction is lost if you look at standards like SVG.

** Theming

Owen Taylor (Redhat): Not Content/UI separation but Structure/Look separation

** Theming (2)

Owen Taylor (Redhat): Can we standardize on what a theme looks like? A magic theming box central hub to eliminate the m-cross-n problem?

** Questions:

Steven Pemberton (W3C/CWI): I have good news -- XForms is the third one, it is the third model.
Owen Taylor (Redhat): I can't really comment:
Steven Pemberton (W3C/CWI): Ask Mark Birbeck for a demonstration.

Glen Gerston (Ideaburst): Why should you confuse the user to make the app look like a desktop app?
Owen Taylor (Redhat): I could deal with web and native looks, but a different look for every web application keeps users from learning what a look does.
Glen Gerston (Ideaburst): Why not have a unified look and feel for all Webapps?
Owen Taylor (Redhat): I suppose you could try but it would be very challenging. Graphic designers would not want to standardize as they want branding. Theming is important for accessibility, for high contrast, for example.

Bert Bos (W3C): I like theming but I would also like to create an application that works on telnet.
Owen Taylor (Redhat): You need multiple levels of abstraction. Doing both a graphical and command line user interface would both be hard. Theming is good enough for application designers and GUIs.

Mark Birbeck (x-port.net): I agree with a lot of what you say; but I think that theming is the least of the problems. A GUI and a voice system are different in so many respects. We know there are many ones to brand in theming but the real way to get productivity benefits is that W3C should standardize on some widgets. For example you could combine 4 XForms input statements and combine them to an IP address control, abstractly, and not theme it.
Owen Taylor (Redhat): You can build up controls from bigger controls but that isn't always the case. You have to be able to extend the widgets. Maybe it is interesting to define 20 widgets, but that's not all we would ever need.

Rich Schwarzfegger (IBM): You can't resize fonts on a dialog box in all systems. You have to have some restrictions on platforms.
Owen Taylor (Redhat): The theme may be platform specific, but the interface should be the same.
Rich Schwarzfegger (IBM): You do have to factor in device capabilities.

* Sarah Allen, Laszlo Systems

** The future of the web is not the past of Windows

Sarah Allen (Laszlo Systems): (demonstrates Laszlo Contacts app in Internet Explorer) It is delivered in browser and looks like Windows. You can also see the source code. Consumers and commercial web sites envision a qualitatively different experience.

** Earthlink start page

Sarah Allen (Laszlo Systems): This portal app provides a start page. You can see lots of data with the Laszlo pane, rich media, responsive UI, etc, with a TV look-and feel. The user can customize the look and feel of the app and the layout. Notice the animations that give indicators to each you how to undo the actions.

Sarah Allen (Laszlo Systems): Laszlo calls this the "cinematic user experience."

** Laszlo Calendar

Sarah Allen (Laszlo Systems): The whole app doesn't refresh, just the data that comes from the server. The animation is used to show the user where they are going, where they have been, and maybe how to get back there.

** Component set

Sarah Allen (Laszlo Systems): These components don't look like the OS but users understand them. They are keyboard navigable. They are written in LZX, the Laszlo XML Language. It must be expressive enough to do that so authors can write their own.

** CES Rich Media Message

Sarah Allen (Laszlo Systems): You can drag and drop photos and clip art. This application uses built-in and custom components. The scroll bar is branded to match the Kodak color. I preview it on the phone.

** Introduction to LZX

Sarah Allen (Laszlo Systems): (Gives demo http://laszlosystems.com/lps/laszlo-in-ten-minutes/ )

Sarah Allen (Laszlo Systems): The XML hierarchy clearly defines the view hierarchy.

Sarah Allen (Laszlo Systems): For data binding we use XPath. We have <dataset name="dset"&ht; inline with <text datapath="dset:/"...> to bind to it with XPath.

Sarah Allen (Laszlo Systems): It can be awkward to re-use code. In Laszlo we have an example of three views and make it a named class. It extends view and now generates a red box. I then use box and gradually transform the program into object-oriented program. You can define attributes and events and methods.

** Conclusion

Sarah Allen (Laszlo Systems): For standards, a language for web applications should provide base level building blocks and standard UI controls.
TV Raman (IBM): Can you give me a sense of what kind of markup abstraction? Is it a package of Java or C++ objects or higher level?

Sarah Allen (Laszlo Systems): We have a set of foundation classes such as views, animators, states, and layouts. There is a rich set of basic building blocks for web applications. There is a set of tags on top of those using the class system provided by Laszlo and that can be built by developers.
TV Raman (IBM): How accessible are these apps? Could I re-purpose an app to a new UI metaphor without a mouse?
Sarah Allen (Laszlo Systems): Most of our effort is for visual UI but the front and and back end are abstracted.
Sarah Allen (Laszlo Systems): This happens to play back in SWF and we use the Flash player for drawing and script interpretation and it is a ubiquitous runtime, but we are not dependent on it.

David Temkin (Laszlo): People seem to be saying that we should reconfigure for other devices automatically. And that doesn't work.
TV Raman (IBM): Yes and no. Experts should write the best-of-breed UI for the back end.

Leigh Klotz (Xerox): I noticed your dataset element is almost exactly the XForms instance and the text element with XPath expression is almost the XForms input control. Is there a reason you didn't use the XForms data model and put your own user interface controls on it?
Sarah Allen (Laszlo Systems): I am not an expert in XForms and I know that people in Laszlo did examine it but we are about putting a UI on the data, not about a UI for any data.
Leigh Klotz (Xerox): That's why I suggested just the XForms data model. I'd recommend you ask your designers to take a second look.

* Vincent Mahe France Telecom

** Our preferred approach

Vincent Mahe (France Telecom): Rather than mixing existing SMIL/SVG/XHTML profiles, create a new format for extend and existing format.

Vincent Mahe (France Telecom): We would like to introduce the concept of "class" of application:

We would like to introduce 3 predefined classes: The idea is not

* Joshua Randall, France Telecom, Web Applications: Dynamic Updating with Remote Events

** The Request-driven web

Joshua Randall (France Telecom): The web is traditionally request-driven but "web applications" today have worked around this by using polling. Many applications simply reload themselves. Polling is bad because it limits the refresh rate and creates network traffic.

Attempts to use polling "efficiently" result in huge scripting hacks when the desired functionality was simple.

** What could we do instead?

** Why evolve?

Polling is not usable on mobile terminals. Mobile devices need a solution now. We can use this experience to steer the evolutionary approach that comes next.

** How to evolve?

** Questions

Alex Hopmann (Microsoft): Polling is a huge problem, but the web service standards that are being developed can take this on. Indigo will support bidirectional message passing.
Joshua Randall (France Telecom): Just abstract away the remote events and build on other event models.
Alex Hopmann (Microsoft): I feel strongly that the protocols be consistent with mainstream web service protocols. The eventing models that work well on a local object model aren't good for remote eventing. Async and queuing are very different. Ordering, transactional, etc.

Dave Raggett: Your colleague Keith Waters is working on this from an application point of view.

Joshua Randall (France Telecom): They discovered the need in the multi-modal group but aren't necessarily the group to standardize it. Dave Raggett: One level is the markup and the other is the low-level SIP/Web Services/HTTP etc. Different groups.
TV Raman (IBM): There are three important points:

Mark Birbeck (x-port.net): Do we need an HTTP Sever on every desktop now?

Alex Hopmann (Microsoft): No, an HTTP Listener for async responses.

Mark Birbeck (x-port.net): How about an onmail event like an onclick event? We should just make XML Events cross-document and networked.

Alex Hopmann (Microsoft): I think that event types are operating system specific.

Leigh Klotz (Xerox): Network events are a solution the problem of letting an application know about state changes. We are using XForms instances to represent state and the events are not transferred, just the state when it changes. but the 80/20 solution is just to provide the state, let the server hang until it changes, and return a small instance document that the client application can bind to. This is done in three lines of XForms markup, but the use case could be codified in the XForms spec as incremental="true" on the instance to have it reloaded. This is like like event registration and would work today but it avoids the performance penalties associated with HTML polling, as you have to load only the small amount of instance data that is associated with the change, and the server is responsible for returning the changed data. In XForms, form controls bound to data that isn't present aren't shown, so when the small instance comes back from the server, the form controls automatically appear. It works quite well and works in XForms today, and the behavior could (and should) be reduced to a single attribute on the XForms model.

* Break

* Non-presenter position papers

Jon Ferraiolo (Adobe): One slide per paper.

** Access:

** Alex Danilo

** Nokia

** Openwave

** Origo

** RIM

** SAP

Jon Ferraiolo (Adobe): Who knows what RIML is? Six. RIML is a consensus project with the EU advancing interoperability and cross-media publishing. They said that for RIML a call to action was to coordinate with W3C.
Steven Pemberton (W3C/CWI): Rendering Independent Markup Language

** SchemaSoft

Jon Ferraiolo (Adobe): They wrote a paper two years ago about namespace boundaries. It's a good paper.

** Patrick Schmitz

** ZoomOn

* Discussion Period

** SVG Tiny

Chet Haase (Sun): I don't see why SVG Tiny isn't useful on other platforms; it seems poorly named.
Chris Lilley (W3C): Tiny is a subset of Basic. As someone pointed out, when you have a code-size requirement, you get more tight on requirements. It's not mobile specific. The bigger devices have to be able to render the smaller subsets. The same is true of XHTML Basic and SMIL Basic.

** XForms Basic

Leigh Klotz (Xerox): XForms Basic is the same document type as TV Raman pointed out, but throws out Schema complex type validation, which means you don't really need an XML Schema processor at all, but you get richer experience.

** "Implements"

Tantek Çelik (Microsoft): Are the devices that claim to implement SVG and the "IE 7" Plugin thing, are they actually passing test suites? My experience is that such things are a prototype proof of concept.
Chris Lilley (W3C): Yes, publish test suite results.
Tantek Çelik (Microsoft): I agree. It takes years to get implementations. You help develop a test suite. Some W3C test suites that were invalid are still invalid three years later.
TV Raman (IBM): Tantek is right about test suites. The "IE 7" not-plugin/plugin non-downloadable/downloadable thing breaks quickly because it is not tested. Voice Browser 2.0 spec has an enormous number of implementations and test suites, and XForms as well, which has a test suite and its test suite report is implemented as an XForm. Tantek is correct that a prototype is nice, but only a proof of contest. We did those in 2000 and 2001 in those gave us a solid design, and today we have solid implementations.

** Implementation Cycles

Glen Gerston (Ideaburst): We started writing SVG applications in 2000 using the Adobe SVG 1.0 browser. I think we have most of the tools. It's more of a focus on what is needed to make them ubiquitous. We have our own programmatic/XML widget set, as Laszlo has done in their XML language. I would like to see WG focus on cross communications between apps and the documents that contain them, and tools. Jon suggested that we demo some tomorrow.

Mark Birbeck (x-port.net): What do we mean by a web application? We think that compound documents and Webapps are not two separate days. For example, it would be good to define a TODO List application and show it on any system. The one in SVG would look fantastic, and Laszlo too, but could we all share the same application? Share the markup? And have applications grow in a distributed fashion across systems? As Alex said, about what customers want -- the idea of being able to use the web architecture to distribute things, and people get the updated application by navigating to a URL. That's the new generation. We saw a fantastic game in JavaScript, but there is a whole other magnitude of productivity we can get to if we can do it in markup.

Mark Birbeck (x-port.net): In New York, on the Semantic Web, you cannot implement all of this without a declarative implementation engine. Unless you have a flexible architecture not based on scripting, the architecture is not manageable.

Alex Hopmann (Microsoft): The question that I ask everyone to ask themselves, is why and in what specific cases do I care about interoperability? When I build a task application, is the goal of this group of people that we define a lot of stuff so I can build applications like that and run them in different platforms and applications? Or would a more interesting goal be defining the kinds of data that the application operates so I can use it on all the platforms? Reading the Red Hat position paper, people seem to think they are building cool stuff with Gnome and GTK, and my friends at Apple, and we at Microsoft think the same thing. It's not true that you could define a single application that can run in all of those places for those to be good platforms. On my PC and phone, in practice, there are different characteristics about those devices; I want different UI interaction models. It's worth it to build a UI version, and on the Mac I hated it when people built software that didn't look like Mac software. One of the key messages at Microsoft was to build specific applications for the Mac audience. Tantek can comment on this, but interoperability is not just the same app on the platforms, but making them work together on the same data. Focusing on where it helps the apps. Thanks.

Bert Bos (W3C): On a nice platform it is good to have applications that use special features. But that doesn't exclude things that you use once in a while. When you use something heavily you want it more adapted. For a tax form, or for IRC if you don't use it often, I don't need a special Mac app.

Alex Hopmann (Microsoft): I heard two points:

Glen Gerston (Ideaburst): We built a Visual Building Search for Adobe in SVG. Adobe doesn't use all Microsoft -- they use Mac and other systems. Having a web distributed application is very useful. We don't have a true cross-platform runtime environment. In the corporate world, not everybody has the same machine. Being able to develop applications once and deploy them across the enterprise is good, and saying developers have to deploy them across the enterprise is ...

Chet Haase (Sun): I agree. We have the capability to do that today, but people need interoperability. What we have today is really crappy HTML forms. We should raise the bar.

Owen Taylor (Redhat): We have a spectrum of things for native applications; fastest response, most useful, broadest range of APIs. If we want them all at once, then we have native app or document with forms. Maybe they want to enhance the document a bit with JavaScript menus or put some code on the client side. People don't always want a web app; sometimes a native platform-specific GUI is best, but there seems to be demand out to me.

David Temkin (Laszlo): XAML appears to be blur the line. I could browser a XAML site from a browser. There is no distinction from a user's viewpoint, and even from development cycle it is very simple. They will seem one and the same from users. The web is all about documents with simple forms. The web goes the way of ASCII then. It's not going away, we're not going to upgrade it. There is the need for a cross-platform way of doing what we learned off the web. Don't put the web in amber and get it over with.

Jon Ferraiolo (Adobe): Here is the Ideaburst SVG demo for Adobe. It's deployed as a web application.

Matt May (W3C): My list of things that people are hacking with JavaScript is not boiling the ocean. I don't mean expose all of .NET to the web. These are relatively limited things that XForms for example does well. When you get the level of effort to coordinate and do this, people are dying for this. They want to update a cart without throwing away the whole page. It can be styled to look like an OS or preferences, as CSS does, but the basic thing is that you can't just say "the web is going to be like this." People are demanding more of it. We can't just say "Let's create JavaScript class libraries for code rooted in 1994."

Steven Pemberton (W3C/CWI): I have a lot of good friends in Microsoft and this may sound aggressive, and I know Microsoft isn't one monolithic organization, and I am really interested in an answer. You said at the end of your talk that the W3C should do decorative markups. But when I look at XAML (little bits of it) and I see the Vector Graphics language, you've renamed a few things, but it seems pretty familiar and a lot like SVG. So my question, is why should we listen to what Microsoft thinks we should do?

Alex Hopmann (Microsoft): I was thinking of wearing a bull's-eye T shirt... I decided to be upfront and open about our plans, and I don't know if you believe it is the truth, but I feel comfortable with it, but I present the facts as I see them. Think for yourself and agree or disagree. I expect a lot of disagreement; I have been part of standards activities on the IETF. I have seen places where attempts to create interoperability are successful, some failures, and some middle ground. I am trying to share experiences on that. We have Avalon graphic primitives and there are some similarities to SVG, but we go beyond the basic stuff for interoperability and we are trying to push limits with our 3D support. The core low-level rendering system innovation is there if you dig deep. We took the approach that XAML is direct mapping to objects. For the basic stuff, other than XML specs for well-formed and verifiable standard XML, we decided not to use any existing standards, and we made a decision that our priority in the design would be support for direct mappings to the .NET objects.
Leigh Klotz (Xerox): (Reads back last sentence for checking.)
Alex Hopmann (Microsoft): This does not preclude developers writing standards compliant implementations. We have a timing issue, as GDI came before SVG, but it's the same thing; it just doesn't happen to be.

Alex Hopmann (Microsoft): There are other places where you need to have things written once and deployed, such as the Adobe building search. What's interesting is that it is mostly targeting the Adobe SVG viewer. It suits their needs. It's also a great thing that servers can get involved, providing some level of interactivity where the server provides some rich processing. If you look at the size of the APIs and the complexity of APIs, the latest DOM spec is 221 pages. And the test suites are not accurate or valid. The reality of doing interoperability without debugging the top 1000 sites is really hard work. There's a lot of work to get the XHTML and CSS stuff to the level to interchange basic content. In the web services work, there is work there. Then you have arbitrary messages and need to define Schemas. There's a bunch of stuff where you focus on the interchange needs and can serve the community in important ways.. A lot of that stuff works, but what do we do when we want to focus on developing something that looks like a normative spec.

Ian Hixson (Opera Software): ??? is ASCII compatible.

Daniel Austin (Sun Microsystems): We have a solution that works on every platform, called Java. It's not a shameless plug for my employer. Bert said that writing good Java code for all those platforms is an investment. If we come up with some solution or smorgasbord or patchwork, X*, is that going to be any less complicated? As the Microsoft guy pointed out, if we build a complex solution to the problems, it won't be any better than what we have today. The mobile guys always want it to be simpler than it really is. Maybe we can't solve it with solution less complex than what we have now.

Mark Birbeck (x-port.net): Java could solve the problem we're trying to address, but interoperability is obviously very important. It's one part of what I'd like to see in web applications. It's a bit like patterns: can we start to make use of that approach? Take the tax form from Bert that Alex thinks is too complicated for web apps. The patterns today are too complicated -- decorators and so on. But a tax form is a few simple rules -- add these columns, subtract three, etc. They recur everywhere. The Adobe search thing is a pattern, an hierarchical search with narrowing. If we can get those out into patterns, you would get a level of productivity far beyond anything we have at the moment. It's like cut and paste, a table, a bit, a JavaScript menu. Now every web site has mm- at the beginning because everybody copied some Macromedia stuff. That's what I mean by a new generation of application.

David Temkin (Laszlo): I would suggest you take a close look at our stuff...but anyway, we haven't talked about a portable runtime that runs everywhere. Then markup can change and I can change my renderer. We like Java, at Laszlo, but we love it on the server. Java has not taken root on the client. ... Does the spec say what the drawing order is when implemented? What we need is a runtime at a low level that runs everywhere. I'm sure .NET will deliver but it will be Windows only. With all the caveats around it, there is the Macromedia Flash player. It is slow though.

John Boyer (PureEdge Solutions): I want to discuss the comments from Sun Microsystems about Java. A case study: we did an application for Nike recently using declarative markup, a computation system. They wanted to do comparison with declarative markup vs in house. So we did a demo app with a set of requirements. The in house group said 1 month to find out how to do it using HTML, JavaScript, and Java. Our guy in that same day provided the application. This is not to say there are no instances in which you might want to drop a JAR into a form for a particular problem, but in most cases declarative is easier. I will demo our forms tomorrow, and they are not simple.

Matt May (W3C): When it came out, Java was too slow. It has expanded and is still too slow. The JavaScript layer is getting that weight. Why don't we just put that into the objects themselves? 95% case of people writing VB apps -- adding form data to a database, creating tables and charts. It's not brain surgery. Having a platform that can expand in an evolutionary manner.

Alex Hopmann (Microsoft): The CLR runtime is an ECMA Standard. The Gnome guys have a project called Mono. The issues with Java are not the basic runtime. The complexity comes from providing the support infrastructure. It's great to ship code, but it has to call something to manipulate and interact with the world. The bindings on the local machine are where the complexity comes in. Our approach tends to be to highly tune things -- for example, our 3D driver-level architecture in Longhorn. People have tried to build 3D architecture in DHTML and SVG. Perhaps that creates a fragile platform. On prototyping: for OWA, I got a reputation because we'd add new features to the app in less than a week. Getting those features to the quality level we wanted took a year and a half. You need that richness to finish the stuff. The US tax code is a 10,000 page document. For simple cases it's fairly simple. I wouldn't disagree but a simple web page, but it's compelling to have a client-side one for privacy. If you get it a little bit wrong you get in a lot of trouble.

Steven Pemberton (W3C/CWI): Just because it's a little bit wrong means you do want to do it declaratively.

Alex Hopmann (Microsoft): Almost every forms-based application you can get to a point where, for example for Amazon or Google is separate, but for other applications, for Exchange, our customers said 80% of what you needed were done declarative and then the rest done imperatively and it's hard to make it portable.

Håkon Lie (Opera): Java would be a clean model, but it didn't work out for some reason. JavaScript won the Turing-complete competition on the web. That's unfortunate; we have JavaScript as much as anyone else here. We have to deal with it. You can write clean JavaScript or clean HTML. Any W3C spec can be used that way though. I don't believe in clean new worlds.

TV Raman (IBM): Håkon you sound tired again. You should pass the mantle. Steven Pemberton said what I was going to say with tax forms. It is a very good example of why you don't want it in the embedded program that the person who understands the tax code can't maintain. That's why you need a framework that reads the tax code declaratively. Factoring out the data from the application has always been a good way of programming.

Peter Cains (Adobe): I am the product manager for PDF at Adobe so please provide me comments.

Vincent Hardy (Sun Microsystems): On Java, it's quite a success in ... Maybe it's not perfect, but it has a number of qualities. It is a VM and available and tested. We agree with the complexity. There is a JCP process for interoperability. My understanding is that the documents can leverage the virtual machine. It's not the machine itself. Complexity is extremely high and Microsoft has mentioned security many times; we have worked on security and built a very secure platform, but it is a daunting task.

Steve Zilles (Independent): We are spending too much time talking about whether we should build an application interface vs. what should be in it? Alex's point is don't try to do it all. Glen said you can do a lot today. Laszlo said you can do it in declarative form. What are the 5 or 3 or 7 things to focus on for the next year to get us to something better? How much better do we have to be before we can say we've done something useful?

Joshua Randall (France Telecom): Java is available on mobile handhelds, but we are unable to offer services because there have to be written differently still. There is a lot of burden on the service provider. Different screen sizes, for example. CSS can start doing it automatically.

Matt May (W3C): I apologize for giving the impression that Java was a failure. I like Java and it is one of my favorite languages. We talked about evolution and revolution. A better analogy is the body; we took deep breaths, we got oxygen. We are at a point where we can't breathe in any more. The poisons are building up and we can't get nutrients; we need to get new things and take stock of what the body needs. Take the second breath. We need to make sure that the people who are using and developing the web get the tools that they need.

Rich Schwarzfegger (IBM): Microsoft said we should focus on XHTML. How do we get those changes into the browser that has over 90% of the market? I have no announcements for rendering technology in Longhorn other than Avalon. Go focus on getting HTML right and make sure the "poisons" don't build up. Rather than tackling a brand new thing...the team that does IE needs to make sure that what we have is secure. We are continuing to invest in browser technology. We need conforming test suites, etc. We're not at the six month development cycles any more. We want to make sure we get it and the security right.

Rich Schwarzfegger (IBM): What's the process for addressing this with Microsoft? You're not in the XHTML WG? I understand you have priorities.

Tantek Çelik (Microsoft): We are in the XHTML WG. I am the representative; recently it has become clear that the priorities of the XHTML WG are different from our priorities. We would like to see the HTML 4 and XHTML 1.x versions resolved. Most of the folks in the WG are XHTML 2 and that is not a priority for us.

Steven Pemberton (W3C/CWI): If you want that done, you have to do it.

Tantek Çelik (Microsoft): If nobody else wants to do it then I don't need to go to the groups.

TV Raman (IBM): With all due respect, XHTML 1.0 has been a rec for longer than IE has been acknowledged to work for.
Tantek Çelik (Microsoft): Where is the XHTML 1.0 test suite? Etc. etc. Etc.
TV Raman (IBM): Shouldn't the vendors be the ones who do that?
Tantek Çelik (Microsoft): The browser vendors should not be the ones who develop the test suites, for obvious reasons.
Chris Lilley (W3C): It worked well for SVG.
Dean Jackson (W3C): Let's end this topic.

Daniel Austin (Sun Microsystems): The same complexity point: that was not intended as a plug for Java but to point out any solution that people ask for is going to be complicated.

David Temkin (Laszlo): For a full operating system, yes it is complex. The web apps as we hear are much smaller. We need a reliable RISC machine. We're not talking about PhotoShop.

Bert Bos (W3C): On Java, I like Java too. Most of the things I want to write are too simple -- I use bash or Perl. Is Java too much like a real programming language? If we had JavaScript on the same VM would people use that?

Mark Birbeck (x-port.net): TV Raman used the word "factoring." You take something you've seen many times before, and you keep recursively deriving things and see what is necessary to build a dynamic mechanism. One of the things we've seen before is loading a document, another is sending it off to a server; that's one or two lines. What other solution is there other than constantly factoring? As the guy from Laszlo said, it's a lot of work to do an application in C++. Every time there's a lot of stuff you could take out or factor out. In XForms there is a dependency tree; there is an XPath expression for them. That's a common component of many applications. That will factor out an enormous amount of work in many applications. Those types of things would make it easier to make applications. It's not just forms.

Paul Topping (Design Science): There's a lot of talk about declarative vs other kinds of programming languages. The AI community has a lot of work in declarative languages. Almost any real application needs an imperative language. Forms might well be that but forms might as well work, but something more complicated is hard in a declarative language. I think people want a simpler world than actually exists. There are a ton of application that won't be able to exist.

TV Raman (IBM): People say if you're doing declarative programming you can't do declarative stuff. Nobody says don't write any imperative code. We started with HTML and added scripting and discovered useful design patterns and moved them back into declarative space. You can do experimentation in the next generation. We touched on the XForms model; people see the model and XPath and Schema. One half of the world says that abstract UI won't work and the other half says that it gives us device independent. The one thing that people miss is that the model and the view are separated. As with Laszlo the data model can be bound to the presentation. You can take an SVG UI, a Laszlo UI, or an XHTML UI and bind it to the TODO model or the tax model. It's not declarative vs imperative.

Chet Haase (Sun): As a developer on Java client at Sun, it's hard and not really applicable to the web space. It's easier to take a powerful large platform like Java and put declarative APIs and make it easier to access.

Leigh Klotz (Xerox): Maybe we should try to get an XHTML+CSS+XForms+SVG client in Java and one in CLR, probably Flash is too slow, and get it out there, and let that be the platform and then stop vying for the pieces of the pie to build that and instead make money by building everything on top of it.

John Boyer (PureEdge Solutions): JavaScript is not declarative. But most of our stuff (even a hypercube sort) is declarative, but our customers drop a JAR of imperative code in applications to handle their business logic.

Dean Jackson (W3C): We should stand and give Leigh applause for taking minutes all day.

Leigh Klotz (Xerox): And to the IRC team for their distributed effort.

Tantek Çelik (Microsoft): And thanks to our hosts as well.

* End of day

** Best quote of the day