Open Web

An independent non-profit dedicated to the development and protection of open, non-proprietary specifications for web technologies. Aimed at building a lightweight framework to help communities deal with the legal requirements necessary to create successful and widely adopted specifications. hoping to break the trend of creating separate legal entities to support individual specifications, coming out of the realization that we could come together and generalize our efforts.

Quest Software, Inc. (QSFT 25.89, -0.08, -0.31%) today unveiled 11 technology predictions for 2011 based on results of its annual survey conducted at The Experts Conference (TEC) U.S., hosted earlier this year by Quest. Survey results were analyzed by Quest experts to extract key insights and compelling trends. Based on analysis of this year's TEC conference survey responses from in-the-trenches IT practitioners, as well as historical perspective gleaned from conducting annual surveys, Quest offers the following 11 predictions about key technology trends and practices. To download the complete description of the predictions or to view the full survey data, please visit

Web 2.0 Summit in San Francisco, Palace Hotel November 14th- 16th (Mon-Wed)

Notification of this article also appeared in the Diigo Document Wars Group..... WebODF...   An especially interesting project that was presented is WebODF, which wants to bring ODF to the web. Jos van den Oever started from the observation that a lot of office suites are moving into the "cloud". Examples are Microsoft Live Office, Google Docs, and Zoho. But where are the free software alternatives for the cloud? For OpenOffice.org, KOffice, AbiWord, and Gnumeric, there are none that have a cloud version with ODF support. That was the motivation for Jos to start a project to fill in this gap and let users view and edit ODF documents on the web without losing control of the document into some company's servers. The strategy Jos followed was to use just HTML and JavaScript for the web application. The application then loads the XML stream of the ODF document as is into the HTML document and puts it into the DOM tree. Styling is done by applying CSS rules that are directly derived from the and elements in the ODF document. That is how WebODF was born; it is a project with the initial goal of creating a simple ODF viewer and editor for offline and online use, implemented in HTML5. The small code base consists of one HTML5 file and eight JavaScript files, each of which is a few hundred lines of code. The most interesting part is that it doesn't need server-side code execution: the JavaScript code is executed in the user's browser and saving the document to the web server is done using WebDAV. It supports both the Gecko and WebKit HTML engines. There is also an implementation on top of QtWebKit, which is for better desktop integration, and an ODFKit implementation. This means that WebODF is an easy way to add ODF support to almost any application, be it in HTML, Gtk, or QML. KO GmbH has received funding from NLnet to improve the current WebODF prototype and see how far the idea goes. Interested readers can try the online demo

Advanced XML, HTML5, XHTML CSS3 editing with conversion to PDF, PDF/A and SVG.  Excellent stuff.  Good Case Studies.  Lots of tools and document source code examples.

The ultimate goals are to have a computer-viewable display format (XHTML) and at least one printable format. We may also want a post-processing editable format. Our farthest target as yet is XHTML, styled by CSS. For a printed format, one expects a complete target to be able to produce a document that has features which one would expect of any Siddur: page numbers, table of contents, footnotes, side notes, header/page title, etc. XHTML originated as a computer-display format, not a publishing format. Even when combined with CSS 2.1, it does not support some of the features above (with some hacking, side notes, a static header/footer, and page numbers are possible, but it is still missing vital features). CSS3 is more publishing friendly, when implemented, will make life much easier. Until then, we will have to be a bit more creative. The following is a list of software libraries and formats that can help us increase the range of formats that we can target. XSLT or Java are the preferred languages, since the rest of our chain is in XSLT, and driven by Saxon, which is written in Java, allowing us to bundle the entire chain in a portable program, which can be distributed ( with the added bonus of being able to be distributed within a web browser as an applet ).

Paquete is a packaging plugin Paquete is a simple package viewer javascript plugin which supports packages like IMS and others where a package is a collection of related pages and content. Paquete describes the relationships within the package using a JSON manifest file. Paquete uses one page to host all of the pages of a package which reduces overall page loading time and allows users to navigate easily. Once an individual sub-page is loaded, it is cached in the host page making browsing much quicker. Specific pages are denoted individually so bookmarking of an individual page is possible. What does Paquete do? Paquete arranges files within the package so there is a table of contents (TOC) on the left-hand side and html pages for viewing, on the right. User navigation can randomly utilise the TOC or the arrowed navigation buttons direct navigation through the package page by page, in a linear fashion. How can Paquete be applied? Paquete can be applied in various ways: on its own, to group files and display them in a browser for viewing. in a Learning Management System (LMS) like Moodle, for viewing course content. in other web applications where navigating through grouped content is important.

The demo movie above from Adobe shows off some WebKit-based experiments that seek to change that. Adobe Engineering VP Paul Betlem narrates and the demo, and he shows how his team is extending the WebKit browser to do some new typographic tricks. WebKit is the open source engine behind Safari and Google Chrome, and it powers the most popular mobile browsers like the ones on the iPhone, iPad, iPod and all the Android phones. The demo certainly shows some impressive results. However, we're a bit suspicious of the methodology behind the results. Betlem talks about extending WebKit's CSS support via vendor prefixes, but neglects to mention what those prefixes are built against - in other words, there's no mention of submitting a standard that other browsers could work from.

transclusion of hypertext documents. Transclusion is technically defined as "when you put that one thing in that other thing". In its current implementation, Twitter has declared that media which is shown within the Twitter interface comes from selected partners. But actually, the technology to allow embedding of rich media from almost any site already exists, using a system called OEmbed. Geeky stuff, but it's made by nice people who are pretty smart, and it lets any site say, "Hey, if you want to put our thing in your thing, do it like this". It works. Lots of sites do it. Nobody's getting rich off of it, but nobody's getting sued, and in between those two extremes lies most of what makes the Web great.

OLE for the Web: oEmbed is a format for allowing an embedded representation of a URL on third party sites. The simple API allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly. Table Of Contents Quick Example Full Spec Security considerations Discovery More examples Authors Implementations

We can all learn a lot of lessons from the history of DDE/OLE/ OLE3/COM /ActiveX/DCOM /COM+ (you can start reading up on Wikipedia to get some background) and how we went from everyone using best-of-breed standalone apps to one integrated, nearly monolithic Office. It basically all started with copy and paste. People who never spent a lot of time in singletasking, character-mode operating environments like the DOS command line don't recall that simply copying-and-pasting information between apps was difficult at the time. And part of the revelation of Windows for mainstream users (or Mac, for leading-edge tech fans), was being able to easily share data in that way. This was different than what Unix users were used to with the command-line pipe, or from what most applications do with feeds today, in allowing structured information flows between applications. There's a desire to combine data from different sources in an arbitrary way, and to have the user interface display the appropriate tools for whatever context you're in. The dominant model here, probably because of the influence of the early PARC demos, is to have toolbars or UI widgets change depending on what kind of content you're manipulating. Microsoft was really into this in the early 90s with OLE2, where your Word toolbars would morph into Excel toolbars if you double-clicked on an embedded spreadsheet. It was ungainly and ugly and slow, especially if you had less than an exorbitant 8MB of RAM, but the idea was pretty cool. And it still is. People are so focused on data formats and feeds that they're ignoring consensus around UI interoperability. The Atom API and Metaweblog API give me a good-enough interface if I want to treat a discrete chunk of information (like a blog post) as an undifferentiated blob. But all the erstwhile spec work around microformats and structured blogging (I forget which one is for XML and which one's for XHTML) doesn't seem to have addressed user experience or editing behavior

Good interview with Charles Jolley - SproutCore - WebKit (met Charles at Web 2.0).  He has left Apple and started a SproutCore Web App development company called "Strobe".  Looking very good Charles! The Blended Brew Apps have become a preferred way of accessing information on mobile devices. But developers want to provide a unified experience, and that is why Jolley believes that we will soon have apps that use HTML5 inside a native app wrapper. "People are looking for an either/or solution, but it is not going to end up like that," he said. Think of Strobe's offerings as a way to create an experience that is a blend of HTML5 and native mobile apps. How this works is that an application is developed in HTML5 instead of proprietary formats. It is wrapped in a native app wrapper for, say, the iPhone, but when accessed through a web browser on a PC or any other device, like tablet, it offers the same user experience. This is a good way to solve a problem that is only going to get compounded many fold as multiple endpoints for content start to emerge. The co-existence of web and native apps also means content publishers need to think differently about content and how it is offered to consumers. The multiplicity of endpoints (iPhone, iPad, TV and PC) is going to force content producers to think differently about how they build the user experiences for different sets of screens. Jolley argues that the best way to do so is to stop taking a document-centric view that is part of the PC-era. In the touch-based mobile device era, folks need to think of ways to have a single technology stack married to the ability to create unique experiences for different devices. And if you do that, there is no doubt that HTML5 and native apps can live in harmony.