Browser Boom
July 14, 2004
Conversation in the XML world is never far away from standards. After all, it was a standard that got us to where we are today. This week the focus is particularly on the renewal of innovation in the web browser and the associated problem of supporting a large legacy user base.
The Curious Incident of the Standards Body in the Night-Time
Web browser innovation has proved to be like the proverbial London bus. You see nothing for ages, then three come along at once. And so Mike Champion pointed out on XML-DEV this week. He mentioned the three new areas of innovation that have arrived at the toes of the media over the last weeks.
Mozilla/Opera collaboration on Web Forms 2.0. "The proposed specifications include new attributes, DOM interfaces and events for validation and dependency tracking as well as XML form submission and initialization. The specification also aims to document existing practices in the forms area that have not yet been officially standardized."
Mozilla, Opera Unite to Standardize Web. "The Mozilla Foundation Wednesday announced a cooperative effort to standardize plug-in functionality, ushering in a new era of multimedia accommodation on today's Web browsers."
New standards. New APIs. Extensions to HTML! But no W3C. What unsanctioned effrontery is this? Perhaps we've missed something and the W3C is behind this after all. Or maybe not, and we're as puzzled as Champion:
So, just at a time when Mozilla, Opera, and Safari seem to be getting some traction ... and there is a need for coordination and standardization of innovative extensions to the browser standards, the W3C doesn't seem to be where it is happening. What's going on? Or what am I missing?
By way of response, Bill de HÓra threw out a link to Joe Gregorio's weblog, where Gregorio explains why he thinks there's no home at the W3C for the directions Mozilla and Opera wish to take.
Gregorio's thesis is that the W3C is being driven by the concerns of those who are using web technologies for intranet, rather than internet, applications. Heavyweights IBM and SAP want to recreate the 21st century's glass teletype.
The biggest problem, the root cause of the disconnect, is the perspective that these companies are coming to the table with. Mozilla and Opera were born, and live on, the web. They get it. That's not to say IBM and SAP don't get the web, they might, but when you say Web Application they are already tuned to a different channel. They're thinking a replacement for their current heavy weight clients. What they're trying to do is build a shiny new 3270 for the next century. In that respect you can see how XForms, SVG and XHTML are ready made pegs for them to hang their thick client hats on. It's not about the internet, it's about the intranet now. It's about creating a XML syntax replacement for the IBM 3270.
David Megginson picked up on the link from Gregorio's piece to the Mozilla-Opera position paper for the recent W3C workshop on Web Applications and Compound Documents -- the rejection of the recommended direction therein being the root of the apparent parting of the ways. Megginson is struck by the position paper's pragmatism.
I don't agree with every single word in the position paper, but it is refreshingly pragmatic, recommending that we build on what we already have and know (HTML forms, JavaScript, DOM, and CSS) instead of trying to rip everything up and start over again. I find myself liking an awful lot of the paper, such as this statement:
If a specification is so large that it requires profiling and/or cannot be implemented on small devices, then it is a failing of the specification that should be solved by editing the complete spec, possibly simplifying or obsoleting some parts.
So now we have an answer to the mystery of the absence of W3C in these latest announcements concerning browser technology. Nobody disagrees that the Web is a messy place. But the majority of W3C participants have only closed worlds as their customer base. They think that throwing away the trash and starting over is the best policy. Mozilla and Opera are steeped in the dirty work of hands-on interoperability, have web content authors as their main customers, and want evolution of the technology. Two very different constituencies.
Let's take this to a practical level for the moment, and look at things from the point of view of a confused web author. Don't we now have multiple sets of complicated standards to choose from? What will happen to the W3C specs we were eagerly pushing forward on? In particular, what about XForms? Having shown some signs of popularity, is the W3C's XML Forms specification to be a casualty of this new energy, overlooked in favor of Mozilla and Opera's Web Forms 2.0?
Before we get too excited, we learn from the Web Forms 2.0 specification that both can coexist:
This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.
XForms 1.0 is well suited for describing business logic and data constraints. Unfortunately, due to its dependencies on technologies not widely supported by Web browsers, it has not been widely implemented by those browsers either. Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on everyday Web browsers.
On XML-DEV, Micah Dubinko also calms the waters and sheds much-needed light on the relative positions of these technologies.
The XForms folks and the WHAT folks are too brilliant not to sort it out, eventually, but the current communications loop (or lack of one, rather) isn't helping.
...
Web Forms 2.0 is trying to cover three kinds of territory:
1) Stuff that works in IE today (autocomplete, but I'd throw in XMLHTTP, contenteditable, spell-check I think)
2) Stuff acceptable if ignored (required, etc., requires a server check anyway)
3) Complicated stuff (repeats, everything else)Everything in 1) should be specified as modules that could be used in either "classic" forms or XForms.
Everything in 2) should be specified as a subset of XForms (probably XForms 1.1, which has requirements to reduce namespace friction). Depending on how deep you need to cut, even XPath isn't necessary....
Other than repeats, which XForms handles adequately, do we need anything else in 3)?
I've a feeling things will get more confusing still before they become clearer. For this week, I'll leave aside the fun and games happening over at Apple, with their unilateral extensions of HTML. But all this innovation has sure kicked up a lot of dust.
Points of Conformance
|
|
|
Also in XML-Deviant |
|
The IETF's constraint that there must be two independent implementations of a technology before it can become a standard has considerable merit. Wishing for such stringency over at ECMA might well be high in the minds of the folks working on the Mono project, an open source implementation of the ECMA Common Language Infrastructure (aka ECMA-335, and more commonly identified with its leading implementation, Microsoft .NET).
The inevitable association with Microsoft's CLI implementation is proving a source of difficulty for the Mono project. The principal author of Mono's XML support, Atsushi Eno, posted to the Mono mailing list on the problems of being conformant in Mono's XML parser implementation. More specifically, whose rules should Mono conform to. W3C or Microsoft?
MS XmlTextReader is buggy since it accepts XML declaration as element content (that violates W3C XML specification section 3 Logical Structures). ... However, there is another discussion that it is useful that new XmlTextReader (xmlText, XmlNodeType.Element, null) accepts XML declaration.
... that error-prone XmlTextReader might be useful (especially for people who already depends on that behavior)
... we did not always reject Microsoft badness; for example we are copying System.Xml.XmlCDataSection that violates W3C DOM interface hierarchy (!)
The root of the dilemma is similar to that which Mozilla and Opera are trying to manage in the browser world. Users moving over from existing implementations will expect a certain behavior, and may well perceive a fix as breakage.
Births, Deaths, Marriages
The latest announcements from XML-DEV.
- Final Program Available for Extreme Markup Languages 2004
-
If you care about markup, don't miss Extreme. A backup brain is advisable. Burn out with the markup geeks! Montreal, August 2-6, 2004.
- New W3C XQuery/XPath Full-Text Working Drafts
-
New draft covering text searching in XQuery. Weighing in at approximately 130 pages when printed, this is full text in more ways than one.
- Second International XML Database Symposium (XSym 2004)
-
As much XQuery and data-oriented XML as you could hope to find in one place. Royal York Hotel, Toronto, 29-30 August 2004.
- Software Development 2005 West Call for Papers
-
Elliotte Rusty Harold's chairing the XML track at SD West once more. "This is not specifically an XML show, so we tend to find that our audience responds better to more practical, how-to, basic sessions as opposed to more theoretical, high-level sessions."
- New working draft for STX
-
STX is a "streaming cousin" of XSLT. The new draft presents a language "much closer to the XPath2/XSLT2 family, avoiding all unnecessary differences from these languages (but still avoiding XML Schema typing, on the other hand)."
Scrapings
XML.com adverts considered criminal ... Schematron vs XSLT, Mike Kay makes a determined case for XSLT ... Messages to XML-DEV last week, 67. Len rating, 7% (must do better) ... XML Schema delusions usually produced by stronger substances than this ... W3C blazing a trail, or trailing the bays?