Dean Jackson (W3C): Welcome. See
the agenda and logistics on the workshop page. What is the
purpose of this workshop? The position papers show a broad range
of ideas. The W3C team and I have organized this workshop to
answer two questions: Is there room for standardization in this
area, and what is the scope?
Dean Jackson (W3C): Introducing Jon
Ferraiolo, co-chair. Philip Hoschka W3C Interaction Domain
Leader. The position papers on compound documents and web
applications overlapped, so we grouped presentations by industry
or association, or area such as XForms or SVG. If you do not want
to present, please let me know; it is not required.
Dean Jackson (W3C): This is a public meeting, so all information, including minutes and list of attendees will be made public. There will be a log of the IRC channel irc://irc.w3.org:6665/#workshop made available.
Bert Bos (W3C): Nearly 10 years ago, HTML was in danger. Extensions for layout made HTML less useful, proprietary extensions, etc. so we created stylesheets. CSS is now being taken up, but HTML is in danger again. JavaScript is the worst invention ever. At first we though we could replace JavaScript with style sheets (rollovers, hover, etc.) and Java for applications, but Java is not so great for simple programs.
Bert Bos (W3C): So, perhaps we need a scripting language or two for the 80%, with the logic separate from the UI so that programs are portable, device independent, accessible, maintainable, re-usable...right from the start. Let's use the knowledge of the web to design something clean that will last for a long time. In my mind, separating the program from the logic is the most important thing, just as we did for HTML, separating the style from the content.
Bert Bos (W3C): Imagine we could start from scratch, leave the difficult 20% to Java, take two years to define our language, and two more years for version 2. (Shows diagram and simulation of three components: UI, Webapp (comprising UI and Logic), and then the Web. That is what we hope to achieve.
Bert Bos (W3C): Imagine and easy high-level interpreted programming language (something like Ruby?), and a 2-way pipe to an easy high-level declarative UI language (something like Gist?). View source for client side. This is perhaps a simple 80% solution.
Bert Bos (W3C): We need to work out the details: UI objects, built-in libraries, security levels, safe local storage, packaging and signing, the MIME type...
Bert Bos (W3C): I will update the slides on line.
John Boyer (PureEdge Solutions): I notice a similarity with what the XForms Working Group has put together. Have you looked at XForms? Bert: Yes, I am not sure yet of the role of XForms. IT could be part of the user interface. My thoughts are still that XForms are good for forms, but not for applications that I have in mind. Fields, yes, but for games or editors, no. XForms is more for as HTML is used. There might be a place.
Mark Birbeck (x-port.net): I characterize Web Applications that those that use the architecture and infrastructure of the Internet. Using HTTP and distribution. It's not a client-side app, it could be server side. It could be desktop. It uses the light-weight features of the Internet, distributing and application as markup. Here we see XForms being used for my slideshow; I would call it a web application. It is all declarative, and the applications are done using HTTP and file:.
Mark Birbeck (x-port.net): I am interested in this area because we had a content management system and wanted to move content from server to server, and wanted to migrate tasks. This opens up the possibility of intelligent agents that can move. I think this is quite profound. The browser, as well, is just another web application.
Mark Birbeck (x-port.net): Generally for mixed-namespace documents, you place a controller at some point in the tree, and this week we say we will resolve it. I think that paradigm is wrong and the web browser is just one application and this is not the correct paradigm for apps.
Mark Birbeck (x-port.net): For example, here is my web browser, and a to-do list at the bottom, built in to the application as a footer in Internet Explorer, running as XForms inside the browser. Unlike what Bert was saying, it is the XForms model that is powerful here. I think this is suitable for desktop applications.
Mark Birbeck (x-port.net): One of the important areas to address is changing what we see as a renderer: as Bert was saying, we should break off rendering. I think we need two DOM trees, one for the application, and then push the rendering off to the last minute. We could usefully standardize rendering. We could have a system tray URL, toolbar, search bar, etc. For example, here is an XForms search bar. The search results bar here uses XForms. There is also a voice rendering going on. We have targeted the voice rendering using the same XForms markup. All of that work needs to be done to break out the rendering into a separate area.
Mark Birbeck (x-port.net): We need to augment the InfoSet to enable serialization (save and resume, agents). Instead of CSS for voice, rendering and color, etc, we should put those as attributes/elements on the InfoSet so that they are in the DOM, layering CSS on that as a selection language for matching those nodes. At the moment, we are taking too long to produce specifications because things like CSS are monolithic and require the authors to be experts in too many areas. So, a plea for pushing as much as possible on the InfoSet. For example, in XForms, you can say that a node is relevant or readonly using XPath expressions. So we could do the same with red, blue, etc. So we can use these specs to create others. Thank you.
Steven Pemberton (W3C/CWI): My
only comment is that I think that the browser issue is
orthogonal.
Mark Birbeck (x-port.net): I agree;
how to we make a bridge between the future that we want and the
present. We treat the browser a renderer, and Adobe SVG plugin a
renderer, and Microsoft Agent.
Philip Hoschka (W3C Interaction Domain
Leader): I read you paper on a standards-based Virtual
Machine. Could you comment on that?
Mark Birbeck (x-port.net): That is
the final step of everything I was saying. If you start at the
ground and say we have the DOM and layer rules on it, and say
that if this node changes that node becomes 5 more than the other
node, add validation, add Schema awareness, add selection
languages like XPath, then that is the basic set of features that
our virtual machine must support. We can move our applications
from one device to another using declarative markup.
Matt May (W3C): A confession: I broke the web. I broke accessibility and compatibility. I started working for HomeGrocer.com and Webvan. We had to create a UI. In 1997-1999, the browsers were limited. We, and everyone else, pushed the envelope of HTML. We invented these things, and took a document format and stripped it of its semantic value, eliminated what it was capable of doing, and turned it into a web application platform. We added cookies, center, font tags, document.write, etc. The ultimate product was an inferior platform for applications.
Matt May (W3C): Real life problems:
Matt May (W3C): I have taken a look at what most script does:
Matt May (W3C): What of these things can't be done declaratively? Look at models such as XForms. The validation stuff is already there. Also SVG and XUL/RBL.
Matt May (W3C): What do we need for accessibility? We need one package. A fragmented approach is inaccessible. Assistive technology developers have limited cycles. Assistive technology developers will pick one, and that will the only one deemed accessible.
Dean Jackson (W3C): In WAI, we have approaches progressive to radical:
David Baron: Some of these accessibility problems are for screen readers interacting with markup (semantic and non-semantic) designed for visual presentation. I am curious how much you have looked at implementations designed from the beginning to be a speech implementation, where you can deal with semantic markup without going through a visual presentation..
Matt May (W3C): I have to defer to others, but the key is in a lot of cases, the browser's role is to expose the DOM or object model to the user. So really whether it is a visual representation or not, it is a bug to the users of the screen reader. They want to extract the original semantics of the document. For Web Applications, those semantics aren't as good. In the long term, it is better to create a set of semantics to render the application as intended.
Vincent Quint (INRIA): I want to address one issue, with answers based on our experience with Amaya.
Vincent Quint (INRIA): Amaya has support mixing multiple levels of embedded elements. Examples: XHTML SVG MathML, XHTML SVG XHTML MathML.
Vincent Quint (INRIA): A single
DOM tree containing all embedded elements makes editing easier. A
single application handles all XML vocabularies. Wrappers such as
object or foreignObject are hidden to
the user. Are wrappers necessary? XHTML+MathML does not use
wrappers. Common parts are shared in the processor and only the
language specificities are handled separately. Example: Here is a
real-life scientific paper. There are a number of different
objects in MathML mixed in the text, in each paragraph. It would
be difficult to edit all of these separately. Integrating into a
single tree makes it easy to manipulate such as document.
Vincent Quint (INRIA): Different modes for editing different XML vocabularies:
Vincent Quint (INRIA): If you want to be more efficient for specific languages, then you need specific views.
Vincent Quint (INRIA): So we can address the complexity of editing in multiple modes with multiple views.
Vincent Quint (INRIA): 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 (IBM): We need to have a WG define what user agents should do, and one for what authoring agents should do, not just markup.
Peter Stark (Sony Ericsson): In
an authoring tool, how does the author know how the elements can
be combined?
Vincent Quint (INRIA): In this tool
only 4 languages are supported. Every language is available at
any time anywhere.
Jon Ferraiolo (Adobe): Let's bring the speakers up.
Bert Bos (W3C): I put something
in the position paper. One part is signing the program who. So
you need a packaging format and XML Signature. Another part is
you need standard communication libraries so you can have control
over what is sent back and forth. I don't know the details. Matt:
It's already happened. Having a model that is actually convenient
to communicate over, using POST or Queries isn't convenient. A
web services model would be beneficial.
Mark Birbeck (x-port.net): There are
two parts to the question: What are the issues in security, and I
want to use script, how do I make it secure? The second part is
like how do you secure your home? I think that script is used to
implement foundations, just as Java/C++/C#, but I think we don't
need script. The advantage of a declarative model is reasoning.
We have semantic web overload from New York, but you can take a
web applications and reason which servers to run the various
parts on to avoid holes. The script itself is out of this
discussion.
Håkon Lie (Opera): Bert
started his presentation by saying he joined W3C to save HTML.
How do you save something? How do you save a village? An
endangered species? Do we save it by freezing it? Or by doing
something totally different? Evolve it? Do we want a revolution
or an evolution? I have my own views after lunch.
Jon Ferraiolo (Adobe): Down the
line.
Mark Birbeck (x-port.net): I've
always been for revolution. This conference is about web
applications, not about saving monolithic browsers. I want to
build applications. I've been programming for 23 years.
Everything I sit down, I worry if I have to get out a C++ or Java
compiler. I want a simple application distribution mechanism. I
want to swap my TO Do list for an Expense form. Our starting
point is not saving HTML.
Bert Bos (W3C): No general but, in
this case, a revolution. Keep HTML, it is getting better, evolve
it, so we don't lose what we can. But make a revolution. This is
the time to do it. We can start thinking about an application
revolution.
Vincent Quint (INRIA): You can dream
of revolution; just defining things like you would like them to
be and starting from scratch. But you can't break everything; it
is not possible. We need to evolve and introduce new features one
after the other to integrate them into the base. Let's define
nice new features but make sure they integrate into the existing
base.
Matt May (W3C): I think that both
sides are evolution. The root for evolution is evolve; the root
for revolution is revolt. We are not revolting against HTML; we
are revolting against people who are using font and center. Get
CSS into the fold in HTML document creation. The long scale is
moving into an application model.
Jon Ferraiolo (Adobe): Great
question!
Steven Pemberton (W3C/CWI): Are
web applications and compound documents related subjects? Does it
matter what the definition of compound documents is?
Bert Bos (W3C): They are different;
In the case of compound documents, it is important to to know. We
need to distinguish between documents like Vincent showed where
everything is in one file vs links. They are not the same thing.
An application can be compound.
Vincent Quint (INRIA): Just a word:
what I have shown is a single document but it doesn't need to be
a single file. That said, I agree with Bert. I decided not to put
web applications in my talk. Compound documents themselves are an
important unsolved issue. We have to develop new techniques. We
can address the two separately.
Matt May (W3C): Compound documents
are the format of a payload to the web applications framework.
You can arrive at mostly the same effect with pointing.
Mark Birbeck (x-port.net): I agree.
The point is that web applications are a special case of compound
documents. There are special issues around compound documents.
There are some issues to pry apart: schemas for editing vs
schemas for running. In XForms you can put an SVG document in a
label. Another distinction is a language for editing vs for
specifying. Do we want to send 20 SVG rectangles or a bar
chart?
TV Raman (IBM): This is an
observation with respect to evolution or revolting. Let's step
back. What HTML was an what it became in the late 90's? HTML got
lost in the gorp of document.write. XHTML 2 is recovering its
roots. The experimentation with script in the late 90's was
discovering what we needed: validation, interaction effects. Now
it's time to codify those and take HTML back to its roots. I
appreciate Bert's saving HTML but we need to take it back to its
roots.
Matt May (W3C): I agree. I think
that what we have right now, what made HTML successful, was that
it satisfied the good-enough technology test. People have taken
HTML 4 as the lingua franca. What we need to get over
this, and the barrier to XHTML 1.1, is part architectural and
part social. People need to see that there is enough value.
That's a revolution. We need the critical mass going forward for
XForms, XHTML 2, SVG. That is how we move past this unattractive
part of the late 90's.
Mark Birbeck (x-port.net): I agree
but there are two worlds: applications and documents that link.
The documents look cleverer but are not applications; for example
they cannot validate your data. There is nothing wrong with HTML
taking its role. But look at Microsoft Money or Quickbooks; they
have embedded within them a browser-rendering technology. At the
end of the day, there is loads of C++ code at the back and the
renderer at the front. Bert is right: we need to address the back
bit now. There are two worlds.
Matt May (W3C): I see that as a
continuum. Add search to an HTML; add send us email address. Is
that an application? It's that transactive model. I'm running an
online grocery; i have 30,000 items in a table. I don't care
about searchability; you have to search through the data itself
(semantic web). When you get to that stage, you see that HTML is
not good enough technology any more. We need to create a
cross-platform web-oriented application platform with some on the
client and some on the server, and make it all accessible.
Peter Stark (Sony Ericsson):
XHTML/CSS, SVG, and SMIL(MMS). Four years ago WML was relevant,
but today it is XHTML. We are also using SVG for simple
animation. We use SMIL for multi-media messages. We use several
web standards for different applications. SVG is a dedicated
player, SMIL for MMS client, and XHTML for browser. They are not
used together.
Peter Stark (Sony Ericsson): Camera
phones an new graphics-based user interfaces raise the bar for
mobile web applications
Dan Zucker (ACCESS): You propose
a mobile profile, but phones get more powerful. Also, vendors
want to differentiate.
Peter Stark (Sony Ericsson):
Profiles drive the industry forward. Vodafone for example, can
drive by requiring SVG 1.1 and then 1.2 next year. So it's good
to have well-defined profiles.
TV Raman (IBM): We should be careful
about saying profiles are good. The pace at which the mobile
industry moves, if we do profiles based on today's devices, what
happens to the content we tie to today's devices?
Peter Stark (Sony Ericsson): The
problem is there are no profile today and you get
interoperability problems.
Chris Lilley (W3C): I agree that
profiles are needed; but just saying what tags isn't sufficient.
Integration with context (where events flow, etc) and conformance
requirements are necessary for authoring tools to work. Otherwise
the authoring tool will ask if you want to export to a Sony
Ericsson or Nokia, etc. We need a CR process for conformance
profiles and then implementation of the platform can provide a
basis for vendor differentiation on top of that platform.
Daniel Austin (Sun Microsystems):
You provide a specific solution to a specific problem on a
specific device. Next year, it will not be useful, just like WML.
What we need is a general solution to how do we mix and
match.
Peter Stark (Sony Ericsson): I agree
first we must solve the problem of how we mix and match, but you
need to have profiles that work. Sometime we exaggerate the speed
at which things move. XHTML Basic was defined four years ago and
it's not until now that you see it across phones.
Glen Gerston (Ideaburst): You put
XHTML Basic, SVG Tiny, etc. Handheld devices get faster and it
takes a year. Is there a reason we are always dumbing down these
specifications? Why don't we look at interoperability between
languages and namespaces?
Peter Stark (Sony Ericsson): I think
there has to be minimal requirements. Also, for some things the
evolution is not as fast as we would like. Next year we may see
SVG Tiny on devices.
Jon Ferraiolo (Adobe): A lot of
these things are not mutually exclusive; extensible architecture
and other profiles are possible.
Chris Lilley (W3C): In terms of the
minimal requirements: DOM Level 2 and XML parser, but eventually
the desktops will catch up to that level.
TV Raman (IBM): You can't separate these two issues.
TV Raman (IBM): The web browser is a means to an end. A web application is characterized by these points:
TV Raman (IBM): In HTML, we factored out presentation. In this go around, we need to factor out interaction, which is eventing.
TV Raman (IBM): Whether I am using a mouse, a cell phone, or a speech UI, the app model is constant. The UI logic and look and feel change. When I was at Adobe, I would ask for people to take the head off the app and give me the app. When you bolt different heads on apps, you see that web apps and web services are the same.
TV Raman (IBM): Web Applications As compound documents. Apps deployed across the network, deployed independently of server. At each point in the network you want something interoperability. For better or worse (mostly better) we have XML and angle brackets. So your compound is a means to that end.
TV Raman (IBM): Consistent eventing model is essential
TV Raman (IBM): See my position paper for more points.
TV Raman (IBM): At the bottom of
the stack we have namespace, protocol, HTTP.
TV Raman (IBM): Next up we have the
XHTML container and the XML DOM at runtime.
TV Raman (IBM): Then we have XHTML
Content in the container styled with CSS.
TV Raman (IBM): Then we have Vectors
in SVG, Voice in Voice XML, Metadata in RDF Triples, and Timing
in SMIL.
TV Raman (IBM): Above that we have
meta things, XSL Transform, XQuery finding, XSchema types, XPath
access.
TV Raman (IBM): Finally, at the top
we have the XForms model and XML Events for eventing.
TV Raman (IBM): Unfortunately, this model comes loose at the seams. We haven't clearly defined the eventing or styling semantics for these languages. So when we mix and match them, it breaks. The xhtml:a element has application semantics. The xhtml:b element has semantics that gets styled as bold.
TV Raman (IBM): See my slides
TV Raman (IBM): We have stagnated in the last 5 years and if you want the web to take off you need to take it to the next level.
Hermann ?: We are looking at Struts and implementing applications. When I hear about declarative compound documents getting smarter, is that it is very difficult to interface the imperative language (Java or C#) into the markup that gets smarter. In Struts and Java Server Faces, if I make a mistake when typing, it may cost me 30 or 40 minutes of looking around because there is no way to interface the Java class with the actual element. This may be part of the larger problem. I am looking forward to declarative markup, but I am having trouble debugging with no tools.
TV Raman (IBM): There are two thoughts: declarative vs. procedural, and your pain. You are having a hard time debugging things on the server. The model on the client has not evolved. You are evolving rich models on the server and then doing printf of HTML and JavaScript. You are writing code that generates code that generates code and that's hard to debug. The client model should be richer and match what is on the server and it is easier to debug.
Daniel Austin (Sun Microsystems):
You started talking about web applications but you addressed
compound document problems. Are there web application problems
that don't match compound document?
TV Raman (IBM): Compound documents
are a means to an end. They won't let me implement a car race
game or the next version of Doom, but I don't care and I don't
want to.
Leigh Klotz (Xerox): Could you
say something about XForms?
Steven Pemberton (W3C/CWI): Their
paper does.
Jon Ferraiolo (Adobe): It seems a
good basis theoretically for W3C applications. It is a tough
question for Adobe, as we don't have any XForms products shipping
at this time.
Steven Pemberton (W3C/CWI): Your PDF
viewer is now called Adobe Viewer. Are you going to be merging
the SVG Viewer and the Adobe Viewer?
Jon Ferraiolo (Adobe): I can't
really comment about future product plans. There are forces in
play that could make Adobe move toward increased support of W3C
standards in our ubiquitous viewing products.
Vincent Hardy (Sun Microsystems): SVG, XHTML, SMIL, XForms...they are silos. SVG is a wonderful technology for graphics, etc. But documents and applications need XMLn. We do solutions redundantly: in SMIL, and in SVG. We need one solution for one problem. It would be nice to use a little of each. What you get by combining is a multiplication factor. We think that we should start working on this. Focus on what application authors want to do rather than any particular technology area. Combining markup delivers a lot of value.
Vincent Hardy (Sun Microsystems): There is no agreement on how to combine them: mixed namespaces, object, foreignObject. But we are not starting from scratch.
Vincent Hardy (Sun Microsystems): Limit integration points. When you load your document and change it through the DOM API you get new difficult problems in validity. In the SVG case we found a domain-specific API was very useful.
Vincent Hardy (Sun Microsystems): Unfortunately, no.
Mark Birbeck (x-port.net): This
is what lead me to thinking we have to go up a level. There will
be new languages. Nobody seems to like the answer to the question
"When will Internet Explorer support SVG? XForms?" We have to
move to a level to where we can combine them. The specifications
you list give three ways to load documents. The specs take years
and are too big. We have to break them down. I don't think that
we can solve the problem if we look at it as XML to the power of
N.
Vincent Hardy (Sun Microsystems):
With smaller profiles and mobile, the implementation complexity
goes down. We have more implementations of SVG Tiny 1.1 than we
did of SVG 1.0 full. It's basic math; the complexity; it's for
domain-specific platforms, but we see results. Complexity goes
up, the implementation cost goes up, and the testability goes
down. The drive is mobile -- their incentive to combine markup is
higher.
Dean Jackson (W3C): Do mobile vendors who didn't present want to add something here?
Suresh Chittori: My question is about time to market from defining a spec and supporting it market. The spec was defined in January of last year and we don't have a good number of products. And how do we define profiles? We should start with common requirements and use cases medium term.
Vincent Hardy (Sun Microsystems): We can talk about how we go about adding features and making sure they are testable. In practice, there is still room for improvement. For SVG, if you want to add a feature you had to come up with the tests. Adding tests early helps.
TV Raman (IBM): The delay is not
because the work is futuristics, but because haste makes waste.
WG's decide they have to do it quickly, take shortcuts, and then
the constraints become irrelevant. In 1992-1993 you could write a
web browser in two pages of Perl. Ten years later we have a more
sophisticated stack that is large and monolithic: XPath, XForms,
XML Schema, are all big and complex, but they are designed to be
modular. If we get this right, at the end of the day, an XML
browser will be easier to write than an HTML Browser of
1999.
Jon Ferraiolo (Adobe): It's hard to
speed up certain processes without making it wasteful. In
general, it is time for the W3C to exert more leadership in
leading the industry, and having an architectural vision, would
tend to increase the focus to standards for market.
Dean Jackson (W3C): I like that question so we'll come back.
Håkon Lie (Opera) I'd like to discuss namespaces. Raman put up boxes on the screen for specs in the years past. Lots of them are meant to be combined with namespaces. But namespaces have problems -- we have implemented them in Opera, but we are still faced with what to do about namespaces we don't know. Micah pointed out that 80% of the issues have to do with Namespaces. Then there is Tantek's proposal for one namespace for W3C. Are namespaces the solution here?
Vincent Hardy (Sun Microsystems): It's is one technique, but it doesn't solve the questions of model and intent. If you mix markup, you may embed a 3D markup in SVG as metadata, or you may want to mix them up with the intent that both are rendered. XML Namespaces doesn't answer that. SVG represents a rendering tree, and XForms has a model element. The nodes represent different things; just because XML Namespaces can mix them doesn't answer the purpose or semantic issue, just the syntax.
Tantek Çelik (Microsoft):
When I proposed a single namespace for document formats, it was
not for all W3C work. The namespaces are the causes of the
silos.
Jon Ferraiolo (Adobe): Pandora's box
is open on namespaces. We can't turn back the clock. C++, for
example uses namespaces, as does Java. There's no way to avoid
it. We can complain about how difficult they are but we are stuck
with them.
TV Raman (IBM): I agree. I put
namespaces and HTTP at the bottom. Nobody throws stones at HTTP,
but until 7 or 8 years ago, they did. Let's talk about eventing
and styling, not casting stones at namespaces.
Charles Ying (Openwave): Content
developers should be involved early on in the spec process. We
are still trying to see mass adoption of SVG in mobile. We are
confident but we need to see content developers involved
sooner.
Steven Pemberton (W3C/CWI): Join the
working group if you want early involvement.
Charles Ying (Openwave): Not
Openwave, but Andrew Wallace or specific design firms.
Peter Stark (Sony Ericsson):
Authoring tool vendors as well. You mentioned SVG -- we did a lot
of work to get SVG into phones but there is no good tool for
creating SVG Tiny documents. We have no good end-to-end
solution.
Mark Verstaen (Beatware): There
are good tools for mobile but W3C doesn't know about them.
Peter Stark (Sony Ericsson): There
are a few tools but not many.
Mark Birbeck (x-port.net): Give them
visibility.
Dean Jackson (W3C): Jon suggested that the W3C take a stronger leadership in developing specifications and said not to rush.
Jon Ferraiolo (Adobe): Work smart, so be efficient. That's what leadership is about; figuring out what is important and do it throughly, carefully, and as fast as you can. Say no to the things that are not important and prevent distractions, to bring increased interoperability to the web, which is the mission.
TV Raman (IBM): Leading the web to its full potential has stagnated because we focused on the web browser. We need to develop new viewers. The question about how to debug the HTML produced on the server is easier to answer if we untie our hands. Don't let the browser do the leading, let the W3C.
Steven Pemberton (W3C/CWI): The 5 years that Peter mentioned for a spec getting critical mass is reasonable. If you produce your spec in 2 years, you then have to get it implemented, get mindshare, and get it used. The same was true with HTML 4. We have to get used to it.
Vincent Hardy (Sun Microsystems):
The cycle in mobile is faster than desktop. When people change
phones you have new devices and new capabilities.
Peter Stark (Sony Ericsson): The
capabilities of phones increase fast. It took several years to
move away from WML to XHTML, and SVG took years.
Dean Jackson (W3C): We have been
working with Vodaphone on the SVG group on a specification for
their Vodaphone Live platform. The implementations follow
quickly.
Bert Bos (W3C): I'd like to hear about profiles; we do them for mobile, how about for desktop. A collective profile, PNG, XHTML, etc. People said it was impossible, but it seems possible for mobile. Are we not pushing it enough? Is browser turnover too slow? Should we work on it?
Jon Ferraiolo (Adobe): One
possible explanation is market dynamics; there are multiple
vendors that need to make money on subscription services and
there is pressure for interoperability and not proprietary
desktop things. On the desktop we have Microsoft Intern Explorer,
Adobe Reader, and Macromedia Flash...
Vincent Hardy (Sun Microsystems): It
takes us back to complexity. The implementation costs are
lower.
Peter Stark (Sony Ericsson): The
industry has a few major companies such as Vodaphone, NTT DoCoMo,
and T-Mobile to set requirements.
David Baron: Namespaces and
componentization, devices-specific profiling. Ten years ago if
someone had asked me to describe what is neat about the web, I
would have said it was universal access to information. Today I'd
still see it that way but it's also applications. I have trouble
understanding the desire for device-specific profiling for
document formats. What are the documents on the web supposed to
be? Are these devices part of a proprietary system?
Vincent Hardy (Sun Microsystems):
Personally, content authors will make decisions based on who can
read content. In the short term, that is SVG Tiny.
TV Raman (IBM): We are confusing profiles and documents vs. what content you deploy on the web. The profile argument at the other extreme that deploying web content in a profile fragments the web like WML. At the same time, authors and implementors need to know what to do; content should be long lived and then address the content in devices in intermediate servers; that is more tractable.
Daniel Zucker: A key issue is that there are 3GPP, 3GPP2, and OMA in the mobile space for standards groups. To avoid fragmentation, now is the time for mobile phones to become a first-class communications device and it's time for the W3C to champion a unified mobile profile.
Mark Birbeck (x-port.net): I feel the standards process question is the most important one of the weekend. Technically, coordination, standards, and discussion and how to get the mechanism into place is important. Profiles say "I like your spec. I don't want to implement all of it as I have a specific problem." It's a subset. So, how do we address that? Maybe the specs should be structured in a different way to take subsets and make them interoperable. Five years is fair enough for a standard, but the process involves creating a standard markup and then analysis, requirements, systems analysis. The markup and syntax is secondary. Let's analyze it and get stuff out quicker in smaller units and draw on them more flexibly.
Daniel Austin (Sun Microsystems): I've been on 12 W3C Working Groups. It's difficult work. For six month timeframes as Peter said, is it worth going through effort to standardize that? Or should we focus on longer timeframes?
Alex Hopmann (Microsoft): There was a time when web browsers were on that timescale, but now we are paying for that now with security issues. Web Applications make the security orders of magnitude more problematic. I am frightened when I hear about cell phones with six month development cycles. I say this with all humility because my company's customers are going through this on PCs as well. Do we need to standardize this that quickly?
Peter Stark (Sony Ericsson): It's important for things like Vodaphone Live to have external standards to focus on; otherwise there will be SVG profiles for the vendors by themselves.
Jon Ferraiolo (Adobe): The
devices get replaced but future devices should run the old
standard.
TV Raman (IBM): XHTML browsers grew
in complexity by adding a little at a time. Mismatched tags,
blink, etc. The devices rev every six to twelve months. What
changes? They get faster, more memory, more bandwidth but more
slowly. The display and your fingers don't change. The quality of
user experience changes; the content needs to be designed for the
long term. It's a big monitor vs. a small display. The cell phone
with a small display may not be a problem as there may be flat
panels around for your cell phone to talk to. Don't dumb down the
markup.
Glen Gerston (Ideaburst): The market factors that push development speed...who wants the device to be fully compliant with the SVG specification? With the 1.0 specification we have a lot of what we need with SVG 3 viewer from Adobe. It's not easy because there are no tools, but that needs a market. How do we accelerate those processes so people can see what can be done? W3C can promote the technology to developers. The cell phone market has a market filling a need. SVG can do this; for desktop, people haven't figured out what SVG can do.
Scott Hayman (Research in Motion): We profiled and modularized in the SVG WG. Everybody knew that the platform was limited. On the desktop, though, you can get implement just about anything, so you end up with a huge spec.
Jon Ferraiolo (Adobe): That brings us up to a 90 minute lunch break.
Håkon Lie (Opera): This is a joint presentation by Opera and Mozilla. The Lemmings game you see here is done in HTML and JavaScript. It is scary inside but shows what can be done. It's not accessible, but we want to make it easier to do this kind of thing.
Ian Hixson (Opera Software): My favorite topic is backwards compatibility. If we want to start over with SVG and so on, we have years of effort. Accessible is frankly not there, but we want a backwards-compatible solution that we can deploy with current or soon-to-be-released browser. Web applications already exist, Amazon.com and EBay.com for example. Documents are becoming interactive as well. But if you view SVG or XForms in today's browsers, you get just text, and nothing works. What we mean by backwards compatible is stuff that works in today's browsers.
Ian Hixson (Opera Software): The parts of CSS, PNG, etc. that are used are the ones implemented in Internet Explorer use. Flash ships and people use it; SVG ships and people don't use it. There are ways to things such as Dean Edward's "IE 7" project done using HTCs (Microsoft proprietary technology), JavaScript, etc., and has supported CSS in IE without binary downloads. Another reason to be backwards compatible is that authors already know HTML and JavaScript. In conclusion, a solution based on HTML is better than one that isn't.
David Baron: When I think about what the web is, it is a system for universal access to information and applications. Specifications should encourage access to all devices, and content should work with all devices. That is not necessarily easy. There are a lot of specifications coming out and making them all work is hard. There is a need to limit the number of documents coming out. But I think that is the wrong solution. Those are signs of a problem that there is too much web or too much (???). I don't like the idea of device-specific profiling. We do have existing mechanisms for separating content from presentation and there is sense in profiling on presentation but not on the content side.
Håkon Lie (Opera) Those are the things we want to highlight. Over lunch, one person asked if Opera is no longer the rebel browser. In this context, we are more evolutionary than revolutionary. We could invent new formats; we did that with CSS. It is a long hard battle. We want to build on what is there and works already.
TV Raman (IBM): So you are saying
you are tired?
Håkon Lie (Opera): We have
some left but want to use it where it makes sense.
Ian Hixson (Opera Software): The
IE 6 upgrade numbers we would need to see. The IE 7 is a
single-line, not downloaded separately.
Alex Hopmann (Microsoft): It's not
an install.
Daniel Austin (Sun Microsystems): There's something called CC/PP. Can we learn from why it has not been adopted for the heterogeneous device problem? I don't want to see us go down that
Other Unidentified Speaker: We don't want to create two webs.Mark Birbeck (x-port.net): As Ian Hixson says there are web applications on the server, but we want to push that work onto the client and make the line more flexible. Showing what we can do today is not interesting. We want to address the problem of things we want to do but can't do today.a People on the SVG list ask about validation and synchronizing form controls.
Håkon Lie (Opera) We shouldn't throw out what we have; we're still here to work.Alex Hopmann (Microsoft): I've been working on standards since 1993 and at Microsoft for about seven and a half years. In the development of IE and Outlook Web Access. Microsoft has been building rich client apps over the web since IE 4. It's been a big focus for us and we hear a lot of demand from customers. There are a couple of consistent things we hear. Capability, manageability, and security are big ones. Security more lately. Interoperability is also something we hear. We look for the biggest value for interoperability and for conflict with the other goals.
Alex Hopmann (Microsoft): For interoperability, we look at protocols and schemas, etc. Customers want to deliver these applications over the network and evolve them quickly. There is a continuum in documents and interactive content. Content is more useful 5-10 years from now. There is an activity to develop it. You want to preserve the essence for the future. Applications tend to have a different lifespan. While I will grant that there are applications still running today that were developed 30 years ago, but they have been tweaked. Certainly for the types of applications that people look at for web apps, we see the need for that agility. The popularity is for updates over management of installed applications. Those developers are always using platform enhancements.
Alex Hopmann (Microsoft): We had a week-long conference on this, but a few key points:
Alex Hopmann (Microsoft): XAML is a markup for specifying a tree of .NET objects. It does not get rid of imperative programming. Part of the application is 100% declarative, and part is written in my favorite language for the Common Language Runtime. It is flexible. It is designed around declarative form tying into accessibility and influences our class library. There is a button tag for the button widget. If you add a MyWidget class there is a MyWidget tag. It influences the design of the class libraries.
Alex Hopmann (Microsoft): We also do 3D graphics, advanced features such as bring-ins and alpha, ???, advanced text support, theming, accessibility, etc. a very broad platform.
Alex Hopmann (Microsoft): The last key aspect is the app model; how do I get the bits to the client? It also involves hosting in the browser window or not. It's not a set of technology choices to run here or there. We are continuing to invest in IE. The reality is that the IE team has been very focused on security work. There is a new service pack coming out very soon, not whiz-bang new features.
Alex Hopmann (Microsoft): We want to to focus on where we are going to be successful. Standards for APIs and Object Models are not going to be successful. That makes a fragile platform, causes security problems, and creates complexity. You could have a simple language, but when you give developers an imperative language, they can do Lemmings or build Outlook Web Access. We pushed the limits of the platform and it was fragile. It's very easy to break edge cases. If you give developers an imperative language they will push it. You also get interactions that cause complicated code paths that cause security problems, call order problems, timing issues, etc.
Alex Hopmann (Microsoft): People should stay focused on declarative content in the W3C and develop long-lived formats. For example, the new CSS3 work is good and doesn't introduce new imperative complexities. Tie things together and build real apps with interoperable web services.
Patrick Schmitz (Nirvana): I used
to work for Microsoft but am now at Nirvana. You talked about
sustaining work in Internet Explorer and what replaces it in
Avalon?
Alex Hopmann (Microsoft): In
Longhorn there is a separation between multiple rendering models,
chrome, and user interface. Avalon can be hosted as well as Adobe
Reader.
Patrick Schmitz (Nirvana): There's
always been a separation there; MSHTML and IE were separate. The
extensions for plugins were there.
Alex Hopmann (Microsoft): We don't
have plans to replace the MSHTML module. It's tuned for rendering
the bug-compatible web. We got IE4 to work with the top 1000 web
sites. While we continue to explore new things for content
formats. That will stay where it is at.
Patrick Schmitz (Nirvana): What
about XHTML and SVG?
Alex Hopmann (Microsoft): We don't
have any announcements to make but obviously you could build
them.
Unidentified Speaker: You said
the button map object and the class...I'm already doing that in
Java. I think it would be of importance in the CLR, is there any
type of effort to let them be known and connected at the CLR
level? Some of this is borrowed from Don Box, where the
expression level of conserved semantics would be higher. How does
XAML connect the imperative C# with the representation?
Alex Hopmann (Microsoft): We
experimented with approaches with XAML. It is an alternative way
to write the constructors. It makes the source code easier to
target. The patterns for reflection etc from CLR and dynamic
properties with change notifications and eventing etc. The
Windows eventing model and the .NET technology is a pattern that
helps the runtime carry forward the declarative
markup.
Alex Hopmann (Microsoft): We don't plan to submit it at this time; it is a markup language for Windows, and W3C is for markup language across systems. We engage W3C for CSS and XHTML. I can't touch on legal issues because I am not a lawyer.
Owen Taylor (Redhat): I have been working on desktops. The diversity is a bit like the web.
Owen Taylor (Redhat): We have to look at matching the look and feel of web applications to the desktop.
Owen Taylor (Redhat): 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 (Redhat): For the "XForms" version, is "UI anything goes?" Every 3D game looks different and the user has to learn it. You have to separate the UI piece into three layers and separate the UI Structure and the Appearance. That distinction is lost if you look at standards like SVG.
Owen Taylor (Redhat): Not Content/UI separation but Structure/Look separation
Owen Taylor (Redhat): Can we standardize on what a theme looks like? A magic theming box central hub to eliminate the m-cross-n problem?
Steven Pemberton (W3C/CWI): I
have good news -- XForms is the third one, it is the third
model.
Owen Taylor (Redhat): I can't really
comment:
Steven Pemberton (W3C/CWI): Ask Mark
Birbeck for a demonstration.
Glen Gerston (Ideaburst): Why
should you confuse the user to make the app look like a desktop
app?
Owen Taylor (Redhat): I could deal
with web and native looks, but a different look for every web
application keeps users from learning what a look does.
Glen Gerston (Ideaburst): Why not
have a unified look and feel for all Webapps?
Owen Taylor (Redhat): I suppose you
could try but it would be very challenging. Graphic designers
would not want to standardize as they want branding. Theming is
important for accessibility, for high contrast, for example.
Bert Bos (W3C): I like theming
but I would also like to create an application that works on
telnet.
Owen Taylor (Redhat): You need
multiple levels of abstraction. Doing both a graphical and
command line user interface would both be hard. Theming is good
enough for application designers and GUIs.
Mark Birbeck (x-port.net): I
agree with a lot of what you say; but I think that theming is the
least of the problems. A GUI and a voice system are different in
so many respects. We know there are many ones to brand in theming
but the real way to get productivity benefits is that W3C should
standardize on some widgets. For example you could combine 4
XForms input statements and combine them to an IP address
control, abstractly, and not theme it.
Owen Taylor (Redhat): You can build
up controls from bigger controls but that isn't always the case.
You have to be able to extend the widgets. Maybe it is
interesting to define 20 widgets, but that's not all we would
ever need.
Rich Schwarzfegger (IBM): You
can't resize fonts on a dialog box in all systems. You have to
have some restrictions on platforms.
Owen Taylor (Redhat): The theme may
be platform specific, but the interface should be the same.
Rich Schwarzfegger (IBM): You do
have to factor in device capabilities.
Sarah Allen (Laszlo Systems): (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 (Laszlo Systems): This portal app provides a start page. You can see lots of data with the Laszlo pane, rich media, responsive UI, etc, with a TV look-and feel. The user can customize the look and feel of the app and the layout. Notice the animations that give indicators to each you how to undo the actions.
Sarah Allen (Laszlo Systems): Laszlo calls this the "cinematic user experience."
Sarah Allen (Laszlo Systems): The whole app doesn't refresh, just the data that comes from the server. The animation is used to show the user where they are going, where they have been, and maybe how to get back there.
Sarah Allen (Laszlo Systems): These components don't look like the OS but users understand them. They are keyboard navigable. They are written in LZX, the Laszlo XML Language. It must be expressive enough to do that so authors can write their own.
Sarah Allen (Laszlo Systems): You can drag and drop photos and clip art. This application uses built-in and custom components. The scroll bar is branded to match the Kodak color. I preview it on the phone.
Sarah Allen (Laszlo Systems): (Gives demo http://laszlosystems.com/lps/laszlo-in-ten-minutes/ )
Sarah Allen (Laszlo Systems): The XML hierarchy clearly defines the view hierarchy.
Sarah Allen (Laszlo Systems): For data binding we use XPath. We have <dataset name="dset"&ht; inline with <text datapath="dset:/"...> to bind to it with XPath.
Sarah Allen (Laszlo Systems): It can be awkward to re-use code. In Laszlo we have an example of three views and make it a named class. It extends view and now generates a red box. I then use box and gradually transform the program into object-oriented program. You can define attributes and events and methods.
Sarah Allen (Laszlo Systems): For
standards, a language for web applications should provide base
level building blocks and standard UI controls.
TV Raman (IBM): Can you give me a
sense of what kind of markup abstraction? Is it a package of Java
or C++ objects or higher level?
Sarah Allen (Laszlo Systems): We
have a set of foundation classes such as views, animators,
states, and layouts. There is a rich set of basic building blocks
for web applications. There is a set of tags on top of those
using the class system provided by Laszlo and that can be built
by developers.
TV Raman (IBM): How accessible are
these apps? Could I re-purpose an app to a new UI metaphor
without a mouse?
Sarah Allen (Laszlo Systems): Most
of our effort is for visual UI but the front and and back end are
abstracted.
Sarah Allen (Laszlo Systems): This
happens to play back in SWF and we use the Flash player for
drawing and script interpretation and it is a ubiquitous runtime,
but we are not dependent on it.
David Temkin (Laszlo): People
seem to be saying that we should reconfigure for other devices
automatically. And that doesn't work.
TV Raman (IBM): Yes and no. Experts
should write the best-of-breed UI for the back end.
Leigh Klotz (Xerox): I noticed
your dataset element is almost exactly the XForms instance and
the text element with XPath expression is almost the XForms input
control. Is there a reason you didn't use the XForms data model
and put your own user interface controls on it?
Sarah Allen (Laszlo Systems): I am
not an expert in XForms and I know that people in Laszlo did
examine it but we are about putting a UI on the data, not about a
UI for any data.
Leigh Klotz (Xerox): That's why I
suggested just the XForms data model. I'd recommend you ask your
designers to take a second look.
Vincent Mahe (France Telecom): Rather than mixing existing SMIL/SVG/XHTML profiles, create a new format for extend and existing format.
Vincent Mahe (France Telecom): We would like to introduce the concept of "class" of application:
Joshua Randall (France Telecom): The web is traditionally request-driven but "web applications" today have worked around this by using polling. Many applications simply reload themselves. Polling is bad because it limits the refresh rate and creates network traffic.
Attempts to use polling "efficiently" result in huge scripting hacks when the desired functionality was simple.Alex Hopmann (Microsoft): Polling
is a huge problem, but the web service standards that are being
developed can take this on. Indigo will support bidirectional
message passing.
Joshua Randall (France Telecom):
Just abstract away the remote events and build on other event
models.
Alex Hopmann (Microsoft): I feel
strongly that the protocols be consistent with mainstream web
service protocols. The eventing models that work well on a local
object model aren't good for remote eventing. Async and queuing
are very different. Ordering, transactional, etc.
Joshua Randall (France Telecom):
They discovered the need in the multi-modal group but aren't
necessarily the group to standardize it. Dave Raggett: One level
is the markup and the other is the low-level SIP/Web
Services/HTTP etc. Different groups.
TV Raman (IBM): There are three
important points:
Mark Birbeck (x-port.net): Do we need an HTTP Sever on every desktop now?
Alex Hopmann (Microsoft): No, an HTTP Listener for async responses.
Mark Birbeck (x-port.net): How about an onmail event like an onclick event? We should just make XML Events cross-document and networked.
Alex Hopmann (Microsoft): I think that event types are operating system specific.
Leigh Klotz (Xerox): Network events are a solution the problem of letting an application know about state changes. We are using XForms instances to represent state and the events are not transferred, just the state when it changes. but the 80/20 solution is just to provide the state, let the server hang until it changes, and return a small instance document that the client application can bind to. This is done in three lines of XForms markup, but the use case could be codified in the XForms spec as incremental="true" on the instance to have it reloaded. This is like like event registration and would work today but it avoids the performance penalties associated with HTML polling, as you have to load only the small amount of instance data that is associated with the change, and the server is responsible for returning the changed data. In XForms, form controls bound to data that isn't present aren't shown, so when the small instance comes back from the server, the form controls automatically appear. It works quite well and works in XForms today, and the behavior could (and should) be reduced to a single attribute on the XForms model.
Jon Ferraiolo (Adobe): One slide per paper.
Jon Ferraiolo (Adobe): Who knows
what RIML is? Six. RIML is a consensus project with the EU
advancing interoperability and cross-media publishing. They said
that for RIML a call to action was to coordinate with W3C.
Steven Pemberton (W3C/CWI):
Rendering Independent Markup Language
Jon Ferraiolo (Adobe): They wrote a paper two years ago about namespace boundaries. It's a good paper.
Chet Haase (Sun): I don't see why
SVG Tiny isn't useful on other platforms; it seems poorly
named.
Chris Lilley (W3C): Tiny is a subset
of Basic. As someone pointed out, when you have a code-size
requirement, you get more tight on requirements. It's not mobile
specific. The bigger devices have to be able to render the
smaller subsets. The same is true of XHTML Basic and SMIL
Basic.
Leigh Klotz (Xerox): XForms Basic is the same document type as TV Raman pointed out, but throws out Schema complex type validation, which means you don't really need an XML Schema processor at all, but you get richer experience.
Tantek Çelik (Microsoft):
Are the devices that claim to implement SVG and the "IE 7" Plugin
thing, are they actually passing test suites? My experience is
that such things are a prototype proof of concept.
Chris Lilley (W3C): Yes, publish
test suite results.
Tantek Çelik (Microsoft): I
agree. It takes years to get implementations. You help develop a
test suite. Some W3C test suites that were invalid are still
invalid three years later.
TV Raman (IBM): Tantek is right
about test suites. The "IE 7" not-plugin/plugin
non-downloadable/downloadable thing breaks quickly because it is
not tested. Voice Browser 2.0 spec has an enormous number of
implementations and test suites, and XForms as well, which has a
test suite and its test suite report is implemented as an XForm.
Tantek is correct that a prototype is nice, but only a proof of
contest. We did those in 2000 and 2001 in those gave us a solid
design, and today we have solid implementations.
Glen Gerston (Ideaburst): We started writing SVG applications in 2000 using the Adobe SVG 1.0 browser. I think we have most of the tools. It's more of a focus on what is needed to make them ubiquitous. We have our own programmatic/XML widget set, as Laszlo has done in their XML language. I would like to see WG focus on cross communications between apps and the documents that contain them, and tools. Jon suggested that we demo some tomorrow.
Mark Birbeck (x-port.net): What do we mean by a web application? We think that compound documents and Webapps are not two separate days. For example, it would be good to define a TODO List application and show it on any system. The one in SVG would look fantastic, and Laszlo too, but could we all share the same application? Share the markup? And have applications grow in a distributed fashion across systems? As Alex said, about what customers want -- the idea of being able to use the web architecture to distribute things, and people get the updated application by navigating to a URL. That's the new generation. We saw a fantastic game in JavaScript, but there is a whole other magnitude of productivity we can get to if we can do it in markup.
Mark Birbeck (x-port.net): In New York, on the Semantic Web, you cannot implement all of this without a declarative implementation engine. Unless you have a flexible architecture not based on scripting, the architecture is not manageable.
Alex Hopmann (Microsoft): The question that I ask everyone to ask themselves, is why and in what specific cases do I care about interoperability? When I build a task application, is the goal of this group of people that we define a lot of stuff so I can build applications like that and run them in different platforms and applications? Or would a more interesting goal be defining the kinds of data that the application operates so I can use it on all the platforms? Reading the Red Hat position paper, people seem to think they are building cool stuff with Gnome and GTK, and my friends at Apple, and we at Microsoft think the same thing. It's not true that you could define a single application that can run in all of those places for those to be good platforms. On my PC and phone, in practice, there are different characteristics about those devices; I want different UI interaction models. It's worth it to build a UI version, and on the Mac I hated it when people built software that didn't look like Mac software. One of the key messages at Microsoft was to build specific applications for the Mac audience. Tantek can comment on this, but interoperability is not just the same app on the platforms, but making them work together on the same data. Focusing on where it helps the apps. Thanks.
Bert Bos (W3C): On a nice platform it is good to have applications that use special features. But that doesn't exclude things that you use once in a while. When you use something heavily you want it more adapted. For a tax form, or for IRC if you don't use it often, I don't need a special Mac app.
Alex Hopmann (Microsoft): I heard two points:
Glen Gerston (Ideaburst): We built a Visual Building Search for Adobe in SVG. Adobe doesn't use all Microsoft -- they use Mac and other systems. Having a web distributed application is very useful. We don't have a true cross-platform runtime environment. In the corporate world, not everybody has the same machine. Being able to develop applications once and deploy them across the enterprise is good, and saying developers have to deploy them across the enterprise is ...
Chet Haase (Sun): I agree. We have the capability to do that today, but people need interoperability. What we have today is really crappy HTML forms. We should raise the bar.
Owen Taylor (Redhat): We have a spectrum of things for native applications; fastest response, most useful, broadest range of APIs. If we want them all at once, then we have native app or document with forms. Maybe they want to enhance the document a bit with JavaScript menus or put some code on the client side. People don't always want a web app; sometimes a native platform-specific GUI is best, but there seems to be demand out to me.
David Temkin (Laszlo): XAML appears to be blur the line. I could browser a XAML site from a browser. There is no distinction from a user's viewpoint, and even from development cycle it is very simple. They will seem one and the same from users. The web is all about documents with simple forms. The web goes the way of ASCII then. It's not going away, we're not going to upgrade it. There is the need for a cross-platform way of doing what we learned off the web. Don't put the web in amber and get it over with.
Jon Ferraiolo (Adobe): Here is the Ideaburst SVG demo for Adobe. It's deployed as a web application.
Matt May (W3C): My list of things that people are hacking with JavaScript is not boiling the ocean. I don't mean expose all of .NET to the web. These are relatively limited things that XForms for example does well. When you get the level of effort to coordinate and do this, people are dying for this. They want to update a cart without throwing away the whole page. It can be styled to look like an OS or preferences, as CSS does, but the basic thing is that you can't just say "the web is going to be like this." People are demanding more of it. We can't just say "Let's create JavaScript class libraries for code rooted in 1994."
Steven Pemberton (W3C/CWI): I have a lot of good friends in Microsoft and this may sound aggressive, and I know Microsoft isn't one monolithic organization, and I am really interested in an answer. You said at the end of your talk that the W3C should do decorative markups. But when I look at XAML (little bits of it) and I see the Vector Graphics language, you've renamed a few things, but it seems pretty familiar and a lot like SVG. So my question, is why should we listen to what Microsoft thinks we should do?
Alex Hopmann (Microsoft): I was
thinking of wearing a bull's-eye T shirt... I decided to be
upfront and open about our plans, and I don't know if you believe
it is the truth, but I feel comfortable with it, but I present
the facts as I see them. Think for yourself and agree or
disagree. I expect a lot of disagreement; I have been part of
standards activities on the IETF. I have seen places where
attempts to create interoperability are successful, some
failures, and some middle ground. I am trying to share
experiences on that. We have Avalon graphic primitives and there
are some similarities to SVG, but we go beyond the basic stuff
for interoperability and we are trying to push limits with our 3D
support. The core low-level rendering system innovation is there
if you dig deep. We took the approach that XAML is direct mapping
to objects. For the basic stuff, other than XML specs for
well-formed and verifiable standard XML, we decided not to use
any existing standards, and we made a decision that our priority
in the design would be support for direct mappings to the .NET
objects.
Leigh Klotz (Xerox): (Reads back
last sentence for checking.)
Alex Hopmann (Microsoft): This does
not preclude developers writing standards compliant
implementations. We have a timing issue, as GDI came before SVG,
but it's the same thing; it just doesn't happen to be.
Alex Hopmann (Microsoft): There are other places where you need to have things written once and deployed, such as the Adobe building search. What's interesting is that it is mostly targeting the Adobe SVG viewer. It suits their needs. It's also a great thing that servers can get involved, providing some level of interactivity where the server provides some rich processing. If you look at the size of the APIs and the complexity of APIs, the latest DOM spec is 221 pages. And the test suites are not accurate or valid. The reality of doing interoperability without debugging the top 1000 sites is really hard work. There's a lot of work to get the XHTML and CSS stuff to the level to interchange basic content. In the web services work, there is work there. Then you have arbitrary messages and need to define Schemas. There's a bunch of stuff where you focus on the interchange needs and can serve the community in important ways.. A lot of that stuff works, but what do we do when we want to focus on developing something that looks like a normative spec.
Ian Hixson (Opera Software): ??? is ASCII compatible.
Daniel Austin (Sun Microsystems): We have a solution that works on every platform, called Java. It's not a shameless plug for my employer. Bert said that writing good Java code for all those platforms is an investment. If we come up with some solution or smorgasbord or patchwork, X*, is that going to be any less complicated? As the Microsoft guy pointed out, if we build a complex solution to the problems, it won't be any better than what we have today. The mobile guys always want it to be simpler than it really is. Maybe we can't solve it with solution less complex than what we have now.
Mark Birbeck (x-port.net): Java could solve the problem we're trying to address, but interoperability is obviously very important. It's one part of what I'd like to see in web applications. It's a bit like patterns: can we start to make use of that approach? Take the tax form from Bert that Alex thinks is too complicated for web apps. The patterns today are too complicated -- decorators and so on. But a tax form is a few simple rules -- add these columns, subtract three, etc. They recur everywhere. The Adobe search thing is a pattern, an hierarchical search with narrowing. If we can get those out into patterns, you would get a level of productivity far beyond anything we have at the moment. It's like cut and paste, a table, a bit, a JavaScript menu. Now every web site has mm- at the beginning because everybody copied some Macromedia stuff. That's what I mean by a new generation of application.
David Temkin (Laszlo): I would suggest you take a close look at our stuff...but anyway, we haven't talked about a portable runtime that runs everywhere. Then markup can change and I can change my renderer. We like Java, at Laszlo, but we love it on the server. Java has not taken root on the client. ... Does the spec say what the drawing order is when implemented? What we need is a runtime at a low level that runs everywhere. I'm sure .NET will deliver but it will be Windows only. With all the caveats around it, there is the Macromedia Flash player. It is slow though.
John Boyer (PureEdge Solutions): I want to discuss the comments from Sun Microsystems about Java. A case study: we did an application for Nike recently using declarative markup, a computation system. They wanted to do comparison with declarative markup vs in house. So we did a demo app with a set of requirements. The in house group said 1 month to find out how to do it using HTML, JavaScript, and Java. Our guy in that same day provided the application. This is not to say there are no instances in which you might want to drop a JAR into a form for a particular problem, but in most cases declarative is easier. I will demo our forms tomorrow, and they are not simple.
Matt May (W3C): When it came out, Java was too slow. It has expanded and is still too slow. The JavaScript layer is getting that weight. Why don't we just put that into the objects themselves? 95% case of people writing VB apps -- adding form data to a database, creating tables and charts. It's not brain surgery. Having a platform that can expand in an evolutionary manner.
Alex Hopmann (Microsoft): The CLR runtime is an ECMA Standard. The Gnome guys have a project called Mono. The issues with Java are not the basic runtime. The complexity comes from providing the support infrastructure. It's great to ship code, but it has to call something to manipulate and interact with the world. The bindings on the local machine are where the complexity comes in. Our approach tends to be to highly tune things -- for example, our 3D driver-level architecture in Longhorn. People have tried to build 3D architecture in DHTML and SVG. Perhaps that creates a fragile platform. On prototyping: for OWA, I got a reputation because we'd add new features to the app in less than a week. Getting those features to the quality level we wanted took a year and a half. You need that richness to finish the stuff. The US tax code is a 10,000 page document. For simple cases it's fairly simple. I wouldn't disagree but a simple web page, but it's compelling to have a client-side one for privacy. If you get it a little bit wrong you get in a lot of trouble.
Steven Pemberton (W3C/CWI): Just because it's a little bit wrong means you do want to do it declaratively.
Alex Hopmann (Microsoft): Almost every forms-based application you can get to a point where, for example for Amazon or Google is separate, but for other applications, for Exchange, our customers said 80% of what you needed were done declarative and then the rest done imperatively and it's hard to make it portable.
Håkon Lie (Opera): Java would be a clean model, but it didn't work out for some reason. JavaScript won the Turing-complete competition on the web. That's unfortunate; we have JavaScript as much as anyone else here. We have to deal with it. You can write clean JavaScript or clean HTML. Any W3C spec can be used that way though. I don't believe in clean new worlds.TV Raman (IBM): Håkon you sound tired again. You should pass the mantle. Steven Pemberton said what I was going to say with tax forms. It is a very good example of why you don't want it in the embedded program that the person who understands the tax code can't maintain. That's why you need a framework that reads the tax code declaratively. Factoring out the data from the application has always been a good way of programming.
Peter Cains (Adobe): I am the product manager for PDF at Adobe so please provide me comments.
Vincent Hardy (Sun Microsystems): On Java, it's quite a success in ... Maybe it's not perfect, but it has a number of qualities. It is a VM and available and tested. We agree with the complexity. There is a JCP process for interoperability. My understanding is that the documents can leverage the virtual machine. It's not the machine itself. Complexity is extremely high and Microsoft has mentioned security many times; we have worked on security and built a very secure platform, but it is a daunting task.
Steve Zilles (Independent): We are spending too much time talking about whether we should build an application interface vs. what should be in it? Alex's point is don't try to do it all. Glen said you can do a lot today. Laszlo said you can do it in declarative form. What are the 5 or 3 or 7 things to focus on for the next year to get us to something better? How much better do we have to be before we can say we've done something useful?
Joshua Randall (France Telecom): Java is available on mobile handhelds, but we are unable to offer services because there have to be written differently still. There is a lot of burden on the service provider. Different screen sizes, for example. CSS can start doing it automatically.
Matt May (W3C): I apologize for giving the impression that Java was a failure. I like Java and it is one of my favorite languages. We talked about evolution and revolution. A better analogy is the body; we took deep breaths, we got oxygen. We are at a point where we can't breathe in any more. The poisons are building up and we can't get nutrients; we need to get new things and take stock of what the body needs. Take the second breath. We need to make sure that the people who are using and developing the web get the tools that they need.
Rich Schwarzfegger (IBM): Microsoft said we should focus on XHTML. How do we get those changes into the browser that has over 90% of the market? I have no announcements for rendering technology in Longhorn other than Avalon. Go focus on getting HTML right and make sure the "poisons" don't build up. Rather than tackling a brand new thing...the team that does IE needs to make sure that what we have is secure. We are continuing to invest in browser technology. We need conforming test suites, etc. We're not at the six month development cycles any more. We want to make sure we get it and the security right.
Rich Schwarzfegger (IBM): What's the process for addressing this with Microsoft? You're not in the XHTML WG? I understand you have priorities.
Tantek Çelik (Microsoft): We are in the XHTML WG. I am the representative; recently it has become clear that the priorities of the XHTML WG are different from our priorities. We would like to see the HTML 4 and XHTML 1.x versions resolved. Most of the folks in the WG are XHTML 2 and that is not a priority for us.
Steven Pemberton (W3C/CWI): If you want that done, you have to do it.
Tantek Çelik (Microsoft): If nobody else wants to do it then I don't need to go to the groups.
TV Raman (IBM): With all due
respect, XHTML 1.0 has been a rec for longer than IE has been
acknowledged to work for.
Tantek Çelik (Microsoft):
Where is the XHTML 1.0 test suite? Etc. etc. Etc.
TV Raman (IBM): Shouldn't the
vendors be the ones who do that?
Tantek Çelik (Microsoft): The
browser vendors should not be the ones who develop the test
suites, for obvious reasons.
Chris Lilley (W3C): It worked well
for SVG.
Dean Jackson (W3C): Let's end this
topic.
Daniel Austin (Sun Microsystems): The same complexity point: that was not intended as a plug for Java but to point out any solution that people ask for is going to be complicated.
David Temkin (Laszlo): For a full operating system, yes it is complex. The web apps as we hear are much smaller. We need a reliable RISC machine. We're not talking about PhotoShop.
Bert Bos (W3C): On Java, I like Java too. Most of the things I want to write are too simple -- I use bash or Perl. Is Java too much like a real programming language? If we had JavaScript on the same VM would people use that?
Mark Birbeck (x-port.net): TV Raman used the word "factoring." You take something you've seen many times before, and you keep recursively deriving things and see what is necessary to build a dynamic mechanism. One of the things we've seen before is loading a document, another is sending it off to a server; that's one or two lines. What other solution is there other than constantly factoring? As the guy from Laszlo said, it's a lot of work to do an application in C++. Every time there's a lot of stuff you could take out or factor out. In XForms there is a dependency tree; there is an XPath expression for them. That's a common component of many applications. That will factor out an enormous amount of work in many applications. Those types of things would make it easier to make applications. It's not just forms.
Paul Topping (Design Science): There's a lot of talk about declarative vs other kinds of programming languages. The AI community has a lot of work in declarative languages. Almost any real application needs an imperative language. Forms might well be that but forms might as well work, but something more complicated is hard in a declarative language. I think people want a simpler world than actually exists. There are a ton of application that won't be able to exist.
TV Raman (IBM): People say if you're doing declarative programming you can't do declarative stuff. Nobody says don't write any imperative code. We started with HTML and added scripting and discovered useful design patterns and moved them back into declarative space. You can do experimentation in the next generation. We touched on the XForms model; people see the model and XPath and Schema. One half of the world says that abstract UI won't work and the other half says that it gives us device independent. The one thing that people miss is that the model and the view are separated. As with Laszlo the data model can be bound to the presentation. You can take an SVG UI, a Laszlo UI, or an XHTML UI and bind it to the TODO model or the tax model. It's not declarative vs imperative.
Chet Haase (Sun): As a developer on Java client at Sun, it's hard and not really applicable to the web space. It's easier to take a powerful large platform like Java and put declarative APIs and make it easier to access.
Leigh Klotz (Xerox): Maybe we should try to get an XHTML+CSS+XForms+SVG client in Java and one in CLR, probably Flash is too slow, and get it out there, and let that be the platform and then stop vying for the pieces of the pie to build that and instead make money by building everything on top of it.
John Boyer (PureEdge Solutions): JavaScript is not declarative. But most of our stuff (even a hypercube sort) is declarative, but our customers drop a JAR of imperative code in applications to handle their business logic.
Dean Jackson (W3C): We should stand and give Leigh applause for taking minutes all day.
Leigh Klotz (Xerox): And to the IRC team for their distributed effort.
Tantek Çelik (Microsoft): And thanks to our hosts as well.