OpenDocument's feed | Diigo Group

Is HTML in a Race to the Bottom? A Large-Scale Survey of Open Web Formats

Fri, 18 Apr 2008 17:53:06 -0000

Highlights and Sticky Notes:

The "race to the bottom" is a familiar phenomenon that occurs when multiple standards compete for acceptance. In this environment, the most lenient standard usually attracts the greatest support (acceptance, usage, and so on), leading to a competition among standards to be less stringent. This also tends to drive competing standards toward the minimum possible level of quality. One key prerequisite for a race to the bottom is an unregulated market because regulators mandate a minimum acceptable quality for standards and sanction those who don't comply.^1,2 In examining current HTML standards, we've come to suspect that a race to the bottom could, in fact, be occurring because so many competing versions of HTML exist.

At this time, some nine different versions of HTML (including its successor, XHTML) are supported as W3C standards, with the most up-to-date being XHTML 1.1. Although some versions are very old and lack some of the newer versions' capabilities, others are reasonably contemporaneous. In particular, HTML 4.01 and XHTML 1.0 both have "transitional" and "strict" versions. Clearly, the W3C's intent is to provide a pathway to move from HTML 4.01 to XHTML 1.1, and the transitional versions are steps on that path. It also aims to develop XHTML standards that support device independence (everything from desktops to cell phones), accessibility, and internationalization. As part of this effort, HTML 4.01's presentational elements (used to adjust the appearance of a page for older browsers that don't support style sheets) are eliminated in XHTML 1.1.

Our concern is that Web site designers might decline to follow the newer versions' more stringent formatting requirements and will instead keep using transitional versions. To determine if this is likely, we surveyed the top 100,000 most popular Web sites to discover what versions of HTML are in widespread use.

The summary statement glosses over the value of a highly structured portable XML document. A value that goes far beyond the strict separation of content and presentation. The portable document model is the essential means by which information is exchanged over the Web. It is the key to Web interop.

Up till now, Web docuemnts have been very limited. With the advent of XHTML-2, CSS-3, SVG, XForms and CDF (Compound Document Framework for putting these pieces together), the W3C has provisioned the Web with the means of publishing and exchanging highly interactive but very complex docuemnts. The Web documents of the future will be every bit as complex as the publishing industry needs.
The transition of complex and data rich desktop office suite documents to the Web has been non existent up till now. With ISO approval of MSOffice-OOXML, Microsoft is now ready to transition billions of business process rich "office" documents to the Web.
This transition is accomplished by a very clever conversion component included in the MSOffice SDK. MS Developers can easily convert OOXML documents to Web ready XAML documents, adn back again, without loss of presentation fidelity, or data. No matter what the complexity!

The problem here is that while MSOffice-OOXML is now an ISO/IEC International Standard, XAML "fixed/flow" is a proprietary format useful only to the IE-8 browser, the MS Web Stack (Exchange, SharePoint, MS SQL, and Windows Server), and the emerging MS Cloud.

Apache, J2EE, Mozilla Firefox, Adobe and Open Source Servers in general will not be able to render these complex, business process rich, office suite documents. MSOffice-OOXML itself is far to complicated and filled with MS application-platform-vendor specific dependencies to be usefully converted to Open Web XHTML-CSS, ePUB or CDF.

XAML itself is only the tip of the iceberg. The Microsoft Web Stack also implements Silverlight, Smart Tags and other WPF - .NET technologies not available as open standards. Silverlight is a proprietary alternative to SVG and Flash technologies. Smart Tags and the LINQ meta search mechanism are alternatives to RDF, RDFa and SPARQL. And of course, XAML "fixed/flow" is a proprietary alternative to advanced XHTML-CSS, CDF, iPAPER, FlashPaper and PDF.

Web formats are important. This survey sadly only begins to scrape the surface of the interoperability problems the future of the Open Web faces. ISO approval of MSOffice-OOXML is going to initiate a great transition of legacy client/server business process systems to a new model of highly efficient, barrier free and cloud ready client/ Web-Stack /server systems.

Hope this helps,

~ge~
posted by garyedwards

Tags: cdf css html ooxml xaml xhtml

Posted by: garyedwards

IE aims to embrace the web again | Technology | The Guardian

Sat, 15 Mar 2008 19:42:35 -0000

Highlights and Sticky Notes:

I asked Hachamovitch, who has led the Explorer team since 2003, why it has taken Microsoft so long to address these deficiencies. "It comes down to what we were doing with our time," he said. "Between 2001 and 2003 we were building what you experience now as Windows Presentation Foundation and Silverlight."

These technologies display not HTML, the language of web pages, but XAML, Microsoft's proprietary code for creating rich visual content.

Tags: css hachamovitch html ie microsoft silverlight w3c wpf xaml xhtml

Posted by: garyedwards

Microsoft Partners with Atlassian & NewsGator - SharePoint Goes Web 2.0 - Flock

Sat, 20 Oct 2007 21:58:32 -0000

Comments:

Pay close attention here boys and girls because here it is. Wonder why Microsoft is wealing, dealing and ready to shell out billions for Web 20 collaboration software? It's to tie them into the MS Stack of MSOffice, IE, Exchange/SharePoint, MS LIve, MS Dynamics, MS SQL Server, etc.

Grand convergence is the convergence of desktop, server, device and web systems. It increasing looks like were going to have to live with the MS Stack and the Open Stack of grand convergence interoperability. One will be able to have perfect interop within it's walls, with all applications able to handle the same compound XML document. The other will be totally unable to implement an inteoperable version of MS-OOXML.

Members of the MS Stack will be able to access everything in the Open Stacks, but outside systems will have limited (crippled) access into the MS Stack. Embrace, Extend, Extinguish. Here we go again.

~ge~

posted by garyedwards

Highlights and Sticky Notes:

4) Linking; Within Confluence, users can access SharePoint document facilities. By including SharePoint lists and content within Confluence, users can (in a single click) edit Microsoft Office documents.

Tags: exchange html ms-ooxml sharepoint w3c web20

Posted by: garyedwards

SynOA What? Syndicated Application Architectures Come of Age - O'Reilly XML Blog

Fri, 21 Sep 2007 15:27:57 -0000

Comments:

Excellent explanation of syndication oriented architectures and the concepts possible impact on the web's future. posted by garyedwards

Tags: atom cdf html json soa syndication synoa xml

Posted by: garyedwards

Indecision in Redmond as Web apps charge : Office 2.0 and Google Apps

Wed, 12 Sep 2007 22:11:40 -0000

Comments:

Great quote from Eric Knorr. He hits the nail on the head here, pointing out the problem Office 2.0 Web Apps and SaaS apps face: If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios. If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process. The only way to overcome that kind of a split is to take the entire process. Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft. As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life. At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser. It's 100% web ready, but only the MS Stack of applications gets to play. Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice. da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys. It can achieve the same high fidelity "round trip" conversion that OOXML is capable of. Maybe even better.

The problem for da Vinci isn't conversion fidlelity. Nor is it capturing business process important VBa scripts, macros, OLE, and security settings. da Vinci can do that just fine. The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!! For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF failed in Massachusetts.

Without these iX "interoperability enhancements", it's impossible to implement ODF anywhere there are MSOffice bound workgroups and business processes. Which is just about everywhere.

So what now?

For the past four months we have been converting da Vinci to pipe into a recent W3C release of HTML+. It's difficult, but we now are certain it can be done with the same high fidelity "round trip" conversion Microsoft achieves with the OOXML plug-in.

The significance of this discovery and proof is that there is a web ready alternative to MS-OOXML and the MS Stack. An alternative that should provide Office 2.0 - Web 2.0 and SaaS apps the same measure of interop - integration with existing documents, applications and processes that Microsoft now enjoys.

The consumer is caught between a rock and a hard place. Waiting for either the ODF or the OOXML gangs of big vendors to blink is a non starter. And even if they did want to harmonize or converge, that in itself may well be a technical impossiblity. The differences between how MSOffice works and how OpenOffice works are directly and "perfectly" reflected in the file formats. And never the twain shall meet.

So here it is. The world is not a clean slate. There are MSoffice workgroups everywhere. Meaning, in real world terms ODF is impossible to implement. Besides that, ODF is a desktop office suite only file format. It was not designed for the Internet, and can only be useful in that capacity through a lossy conversion. OOXML was designed to cover the full expanse of desktop, server, device and web. Only, it's to be a 100% Microsoft dominated and controlled expanse. Which leaves us with one alternative: HTML+

Time to get back to work :)

~ge~

Ref: "Why Can't We All Just Get Along?"

posted by garyedwards

Highlights and Sticky Notes:

the fact is that Redmond could own this new space if it wanted to. All it would need to do is push interoperability and integration between lightweight Web versions of Office applications and its desktop fatware. Advanced features would be absent from the lightweight versions, but the company could ensure any Office doc would load on the Web -- whatever new desktop service packs and upgrades might appear -- and online document management could be integrated with Windows for offline access.

Tags: cdf html odf officeopenxml ooxml opendocument

Posted by: garyedwards