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
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: 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: 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 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: 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: 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: 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: 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 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: 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 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: 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 virtual
machine must support. We can move our applications from one device
to another using declarative markup.
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:
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 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: In WAI, we have approaches progressive to radical:
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: 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: I want to address one issue, with answers based on our experience with Amaya.
Vincent Quint: Amaya has support mixing multiple levels of embedded elements. Examples: XHTML SVG MathML, XHTML SVG XHTML MathML.
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
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.
Vincent Quint: Different modes for editing different XML vocabularies:
Vincent Quint: If you want to be more efficient for specific languages, then you need specific views.
Vincent Quint: So we can address the complexity of editing in multiple modes with multiple views.
Vincent Quint: I would suggest a few words about style. Use different style sheets for different editing tasks, depending on what you are doing on the document.
Support for editing style sheets (CSS)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.
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 trust 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 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: 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: 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: Down the line.
Mark Birbeck: 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: 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: 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: 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: 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
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: 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 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: 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.
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, and
XHTML for browser. They are not used together.
Peter Stark: Camera phones an new
graphics-based user interfaces raise the bar for mobile web
applications
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.
TV Raman: You can't separate these two issues.
TV Raman: The web browser is a means to an end. A web application is characterized by these points:
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.
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.
TV Raman: Consistent eventing model is essential
TV Raman: See my position paper for more points.
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: Above that we have meta
things, XSL Transform, XQuery finding, XSchema 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.
TV Raman: See my slides
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 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: 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: 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.
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.
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.
Vincent Hardy: There is no agreement on how to combine them: mixed namespaces, object, foreignObject. But we are not starting from scratch.
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.
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 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.
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 increase the
focus to standards for market.
Dean Jackson: I like that question so we'll come back.
Håkon: 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: 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
complain 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.
Mark Verstaen: 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 enough? 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
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: 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; 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: 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: 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: 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: 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.
Ian Hixson: 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: 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: 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.
TV Raman: So you are saying you are tired? Håkon: We have some left but want to use it where it makes sense.
Ian Hixson: The IE 6 upgrade
numbers we would need to see. The IE 7 is a single-line, not
downloaded separately.
Alex Hopmann: It's not an install.
Daniel Austin: 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: 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: We shouldn't throw out what we have; we're still here to work.Alex Hopmann: 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: 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.
Alex Hopmann: We had a week-long conference on this, but a few key points:
Alex Hopmann: 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: We also do 3D graphics, advanced features such as bring-ins and alpha, ???, advanced text support, theming, accessibility, etc. a very broad platform.
Alex Hopmann: 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.
Alex Hopmann: 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.
Alex Hopmann: 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.
Patrick Schmitz: 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: 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: There's always been a
separation there; MSHTML and IE were separate. The extensions for
plugins were there.
Alex Hopmann: 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: What about XHTML and
SVG?
Alex Hopmann: 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: 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.
Alex Hopmann: 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.
Owen Taylor: I have been working on desktops. The diversity is a bit like the web.
Owen Taylor: We have to look at matching the look and feel of web applications to the desktop.
Owen Taylor: The W3C shouldn't standardize a whole toolkit and be left behind. Don't put all the big standards in one big heap. How can we make small useful pieces? Don't say XForms+SVG+This+That. It's not digestible.
Owen Taylor: 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.
Owen Taylor: Not Content/UI separation but Structure/Look separation
Owen Taylor: Can we standardize on what a theme looks like? A magic theming box central hub to eliminate the m-cross-n problem?
Steven Pemberton: I have good news
-- XForms is the third one, it is the third model.
Owen Taylor: I can't really
comment:
Steven Pemberton: Ask Mark Birbeck for
a demonstration.
Glen Gerston: Why should you
confuse the user to make the app look like a desktop app?
Owen Taylor: 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: Why not have a unified
look and feel for all Webapps?
Owen Taylor: 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: I like theming but I
would also like to create an application that works on
telnet.
Owen Taylor: 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: 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: 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: You can't
resize fonts on a dialog box in all systems. You have to have some
restrictions on platforms.
Owen Taylor: The theme may be platform
specific, but the interface should be the same.
Rich Schwarzfegger: You do have to
factor in device capabilities.
Sarah Allen: (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.
Sarah Allen: 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 calls this the "cinematic user experience."
Sarah Allen: 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.
Sarah Allen: 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.
Sarah Allen: 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.
Sarah Allen: (Gives demo http://laszlosystems.com/lps/laszlo-in-ten-minutes/ )
Sarah Allen: The XML hierarchy clearly defines the view hierarchy.
Sarah Allen: 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: 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.
Sarah Allen: For standards, a
language for web applications should provide base level building
blocks and standard UI controls.
TV Raman: 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: 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: How accessible are these
apps? Could I re-purpose an app to a new UI metaphor without a
mouse?
Sarah Allen: Most of our effort is for
visual UI but the front and and back end are abstracted.
Sarah Allen: 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: People seem to be
saying that we should reconfigure for other devices automatically.
And that doesn't work.
TV Raman: Yes and no. Experts should
write the best-of-breed UI for the back end.
Leigh Klotz: 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: 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: That's why I suggested
just the XForms data model. I'd recommend you ask your designers to
take a second look.
Vincent Mahe: Rather than mixing existing SMIL/SVG/XHTML profiles, create a new format for extend and existing format.
Vincent Mahe: We would like to introduce the concept of "class" of application:
Joshua Randall: 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.Alex Hopmann: 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: Just abstract away the
remote events and build on other event models.
Alex Hopmann: 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.
Joshua Randall: 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: There are three important
points:
Mark Birbeck: Do we need an HTTP Sever on every desktop now?
Alex Hopmann: No, an HTTP Listener for async responses.
Mark Birbeck: How about an onmail event like an onclick event? We should just make XML Events cross-document and networked.
Alex Hopmann: I think that event types are operating system specific.
Leigh Klotz: 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.
Jon Ferraiolo: One slide per paper.
Jon Ferraiolo: 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: Rendering
Independent Markup Language
Jon Ferraiolo: They wrote a paper two years ago about namespace boundaries. It's a good paper.
Chet Haase: I don't see why SVG Tiny isn't useful on other platforms; it seems poorly named. Chris Lilley: 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.
Leigh Klotz: 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.
Tantek Çelik: 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: Yes, publish
test suite results.
Tantek Çelik: 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: 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.
Glen Gerston: 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: 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: 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: 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: 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: I heard two points:
Glen Gerston: 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: 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: 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: 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: Here is the Ideaburst SVG demo for Adobe. It's deployed as a web application.
Matt May: 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: 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: 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: (Reads back last sentence
for checking.)
Alex Hopmann: 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: 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: ??? is ASCII compatible.
Daniel Austin: 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: 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: 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: 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: 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: 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: Just because it's a little bit wrong means you do want to do it declaratively.
Alex Hopmann: 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: 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: 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: I am the product manager for PDF at Adobe so please provide me comments.
Vincent Hardy: 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: 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: 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: 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: 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: What's the process for addressing this with Microsoft? You're not in the XHTML WG? I understand you have priorities.
Tantek Çelik: 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: If you want that done, you have to do it.
Tantek Çelik: If nobody else wants to do it then I don't need to go to the groups.
TV Raman: With all due respect,
XHTML 1.0 has been a rec for longer than IE has been acknowledged
to work for.
Tantek Çelik: Where is the
XHTML 1.0 test suite? Etc. etc. Etc.
TV Raman: Shouldn't the vendors be the
ones who do that?
Tantek Çelik: The browser
vendors should not be the ones who develop the test suites, for
obvious reasons. Chris
Lilley: It worked well for SVG.
Dean Jackson: Let's end this
topic.
Daniel Austin: 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: 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: 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: 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: 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: 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: 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: 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: 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: We should stand and give Leigh applause for taking minutes all day.
Leigh Klotz: And to the IRC team for their distributed effort.
Tantek Çelik: And thanks to our hosts as well.