Draft W3C Workshop on Web Applications and Compound Documents Jun 1, 2004

* Present

Dan Zucker, ACCESS
Jon Ferraiolo, Adobe
Mark ?, Beatware
Bert Bos, W3C
Alex Danilo,
Hermann , Coolpix
, Design Science
Dubinko Micah, Verity
France Telecom
Helsinki University of Technology
TV Raman, IBM
Kelvin Lawrence, IBM
Glen Gerston, Ideaburst
Irene Vatton, INRIA INRIA
Vincent Quint, INRIA
Laszlo Systems
Dean Jackson, W3C
Jim Ley
Matt May, W3C
Cameron, McCormack
Tantek Çelik, Microsoft
Alex Hoffman, Microsoft
Dave Baron, Mozilla Foundation
Suresh Kittori ,Nokia
,OASIS DITA Technical Committee
Charles Yang, Openwave
Hakon Lie ,Opera Software
,Origo Services
McCormack, Cameron, Independent
Michael, Pediaditakis, University of Kent
Steven Pemberton, W3C/CWI
PureEdge Solutions
Dave Ragget, W3C
Peter Stark, Sony-Ericsson
Scott Haman,Research in Motion
Doug Schepers, Independent
Patrick Schmitz
Sony Ericsson
Vincent Hardy, Sun Microsystems
Daniel Austin, Sun Microsystems
US Advanced Distributed Learning Initiative and IEEE Learning Technology Standards Committee Reference Model (SCORM)
Mark Birbeck, x-port.net
Leigh Klotz, Xerox
Steve Zilles, Independent

* Agends

* Welcome and Introduction

Dean Jackson: 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: Introducing Jon Ferriaolo, 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: 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 chanllel irc://irc.w3.org:6665/#workshop made available.

* Bert Bos

Bert Bos: 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: 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: Imagine we could dstart from scratch, leave hte 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: 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: 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: I will update the slides on line.

John Boyer: 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: I characterize Web Applications that those that use the archictecture 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: 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 possiblilty of intelligent agents that can move. I think this is quite profound. The browser, as well, is just another web application.

Mark Birbeck: 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: 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 insdie 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: 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: 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 bceause 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: My only comment is that I think that the browser issue is orthogonal.
Mark Birbeck: 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: I read you paper on a standards-based Virtual Machine. Could you comment on that?
Mark Birbeck: 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 virual machine must support. We can move our applications from one device to another using declarative markup.

* Matt May, W3C

Matt May: 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: 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 tryng 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: I have taken a look at what most script does:

Matt May: 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: What do we need for acessibility? 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: 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 implmentations designed from the beginning to be a speech implementation, where you can deal with semantic markup without going through a visual presentation..

Matt May: 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: I want to address one issue, with answers based on our experience with Amaya.

** Nesting

Vincent Quint: Amayas has support mixing multiple levels of embedded elements. Examples: XHTML SVG MathML, XHTML SVG XHTML MathML.

** Structure

Vincent Quint: 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 specifities 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: 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: 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: In an authoring tool, how does the author know how the elements can be combined?
Vincent Quint: In this tool only 4 languages are supported. Every language is available at any time anywhere.

* Discussion

Jon Ferraiolo: Let's bring the speakers up.

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

Bert Bos: 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 communuication 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: 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.
Hakon Lie: Bert started his presenation 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 freezeing it? Or by doing something totally differetrn? Evolve it? EDo we want a revolution or an evolution? I have my own views after lunch.
Jon Ferraiolo: Down the line.
Mark Birbeck: I've always been for revolution. This concerence is about web applications, not about saving monolithing 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 wsant to swap my TO Do list for an Expense form. Our starting point is not saving HTML.
Bert Bos: No general but, in this case, a revolution. Keep HTML, it is getting better, evolve it, so we don't lsoe what we can. But make a revolution. This is the time to do it. We can start thinking about an application revolution.
Vincent Quint: 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 teh abse. Let's define nice new features but make sure they integrate into the existing base.
Matt May: I think that both sides are evolution. The root for evolution is evolve; teh 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: Great question!

Steven Pemberton: Are web applications and compound documents related subjects? Does it matter what the definition of compound documents is?
Bert Bos: 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: Just a word: what I ahve 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: 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: 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: 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: I agree. I think that what we have right now, what made HTML succesful, 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: 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: 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: 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, adn XHTML for browser. They are not used ogether.
Peter Stark: Camera phones an new graphics-based user interfaces raise the bar fo rmobile web applications

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

** Questions

Dan Zucker: You propose a mobile profile, but phones get more powerful. Also, vendors want to differentiate.
Peter Stark: 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: 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: The problem is there are no profile today and you get interoperability problems. Chris Lilley: 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: 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: 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: 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: 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: A lot of these things are not mutually exclusive; extensible architecture and other profiles are possible. Chris Lilley: 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: You can't separate these two issues.

** Outline

** Characteristics

TV Raman: The web browser is a means to an end. A web application is characteristized by these points:

** Prerequisits

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

TV Raman: 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,

** Bulding on what we have

TV Raman: 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: Consistent eventing model is essential

TV Raman: See my position paper for more points.

** W3C Building blocks

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

TV Raman: 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: See my slides

* Conclusion: Web Ready to Take Off (Again)

TV Raman: 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 interafe 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: There are two thoughts: declararive 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: 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: 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 Ferrailoo, Adobe

** Recommendations

Leigh Klotz: Could you say something about XFOrms?
Steven Pemberton: Their paper does.
Jon Ferraiolo: 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: Your PDF viewer is now called Adobe Viewer. Are you going to be merging the SVG Viewer and the Adobe Viewer?
Jon Ferraiolo: 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: 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: 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: 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: Could you comment on Sun's XML Processing pipeline?

Vincent Hardy: Unfortunately, no.

Mark Birbeck: 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: 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 complexi; it's for domain-specific platforms, but we see results. ty 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: 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: 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: 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: 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 incrase the focus to standards for market.

Dean Jackson: I like htat question so we'll come back.

Haakon Lie: I'd like to discuss namespaces. Raman put up boxes on the screen for specs in teh uyears past. Lots of them are meant ot be combined with namespaces. But namespaces have problems -- we have implementated 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: 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: 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: 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 complin about how difficult they are but we are stuck with them.
TV Raman: 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 Yang: 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: Join the working group if you want early involvement.
Charles Yang: Not Openwave, but Andrew Wallace or specific design firms.
Peter Stark: 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 loking. 3GP, etc.

Mark Beatware: There are good tools for mobile but W3C doesn't know about them.
Peter Stark: There are a few tools but not many.
Mark Birbeck: Give them visibility.

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

Jon Ferraiolo: 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: 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: 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: The cycle in mobile is faster than desktop. When people change phones you have new devices and new capabilities.
Peter Stark: The capabilities of phones increase fast. It took several years to move away from WML to XHTML, and SVG took years.
Dean Jackson: We have been working with Vodaphone on the SVG group on a specification for their Vodaphone Live platform. The implementations follow quickly.

Bert Bos: 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 neough? Is browser turnover too slow? Should we work on it?

Jon Ferraiolo: 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: It takes us back to complexity. The implementation costs are lower.
Peter Stark: The industry has a few major companies such as Vodaphone, NTT DoCoMo, and T-Mobile to set requirements.

David Baron: Namespaces and componentitation, 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: Personally, content authors will make decisions based on who can read content. In the short term, that is SVG Tiny.

TV Raman: 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;t aht 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: 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 interoperabile. 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: 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 Hoffman: 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 becuase my company's customers are going through this on PCs as well. Do we need to standardize this that quickly?

Peter Stark: 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: The devices get replaced but future devices should run the old standard.
TV Raman: 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: 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 Haman: 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: That brings us up to a 90 minute lunch break.