Public companies worldwide are required to file regular reports setting out the financial health of the company. These are available from corporate investor relations websites and from regulatory agencies like the Securities and Exchange Commission (SEC). If you want to analyze this data, you have to re-key it, which involves a lot of work and introduces errors. That is all about to change.

The SEC and kindred agencies around the world are starting to require companies to file reports in XBRL (the extensible business reporting language). XBRL ties each reported item of data to the reporting concept used to collect it, and moreover, does so in a way that computers can make sense of, avoiding the need for re-keying data.

XBRL will allow investor relation sites to support interactive access and sharing of tagged financial data. This will build upon Web 2.0 and the phenomenon of user provided content on wiki’s, blogs and social networking sites aimed at investors, e.g. wikinvest, where investors share data, insights and analyses. Youtube provides a powerful precedent in the way it allows people to share content by embedding a view or a link to a view in their blogs.

For XBRL, this means providing a way for people to browse the data, and to pull out tables and charts as needed for their blogs. These items could be rendered by the investor relations site and shared à la Youtube, or the blog could itself make use of a script to query data across one or more investor relations sites and render it locally. This is where the Semantic Web and linked open data comes in. I’ve previously reported on techniques for converting XBRL into RDF triples.

W3C and XBRL International are looking for your help in understanding what some people are calling “Investor relations 2.0″, and we invite you to attend a workshop at the FDIC training facility in Arlington, Virginia, this October. We want your help with identifying the opportunities and challenges for interactive access to business and financial data expressed in XBRL and related languages. This doesn’t just apply to the investor community, as the same technologies also offer huge potential for data published by governments on sites like data.gov (see demos). For more details on the workshop see the call for papers.

One of the challenges is the ease with which interactions can be linked across websites. Having to remember user names and passwords for a large number of websites is hard. The increasing use of email addresses in place of user names for signing into websites makes it easier to link interactions across sites since email addresses are globally unique names. OpenID offers users the means to use a single digital identity for accessing participating websites, and relies on the user providing an HTTP URL as a globally unique identifier, with the same drawback as using an email address.

Having to remember lots of user names is much too hard, but using a gloabally unique identifier just makes it easier for people to track your detailed behavior. What’s the solution? I have been thinking about the possible role of a trusted privacy provider. With OpenID you are asked to provide your HTTP URL to the website you are connecting to. Imagine instead, that you are asked to disclose your privacy provider (e.g. through a drop down list or typing a URL). The website then re-directs the browser to your privacy provider to sign in. If this is the first time you have visited the website, your privacy provider will ask you for your privacy preferences for interacting with that site. The approach allows you to effortlessly use a different identity for each website if you wish, and like OpenID avoids the need for you to sign in with every website you visit. There are lots of further opportunities for privacy management, but I will leave those to another blog.

With the demise of the Adobe SVG viewer plugin, there is a need for a new way to deploy SVG across existing browsers. Firefox, Opera and Safari now include native implementations, but Microsoft is keeping quiet on whether it will eventually add support for SVG in Internet Explorer. In the absence of native support, one possibility is to use browser sniffing and convert SVG to Microsoft’s proprietary VML format for delivery to Internet Explorer. VML isn’t as powerful as SVG, so that can cause problems. Another idea is to use a plugin, such as the former Adobe SVG viewer. Unfortunately, most users are very averse to downloading and installing new plugins.

The good news is that pretty much everyone already has the Adobe Flash player according to Adobe’s statistics. Flash has good support for XML, HTTP and graphics, and this suggests the possibility of using Flash to download and render SVG on any Flash enabled browser. I have been working to realize this idea.

My SVGOpen paper and presentation describe a viewer and associated editor that is designed to allow users to create and edit SVG directly on a website from within their browser. Thanks to Flash, this works on all major browsers and operating systems. Traditional drawing tools are standalone applications that need to be locally installed. The user interface is often very flexible and can be a little hard to learn. By contrast, most people expect Web applications to be easy to drive and something you can use the first time you come across it. Fulfilling such high expectations for an SVG editor isn’t going to be easy, but the work is progressing well and I am looking forward to initial user trials.

This also opens the theoretical possibility for XBRL filings to be submitted in one of the RDF syntaxes, e.g. turtle. The current XML syntax makes use of XML Schema to assist with validation of XBRL filings, and it will be interesting to look at validation using Semantic Web technologies as an alternative. I am looking forward to exploring the use of RDF with the rendering linkbase that is under development at XBRL.org.

Properties like location, with privacy and associated legal issues, will clearly be more complicated to deal with, as we will need to address the security and trust models involved. But other properties like battery level, signal strength, light and vibration control, should be much easier to progress.

The Device Description WG is defining APIs for access to properties of classes of devices, and the OMA is defining a protocol and server-side API for access to dynamic properties (DPE) that will enable servers to dynamically adapt media streams to match device orientation and bandwidth. The UWA WG has recently moved DCCI to CR and published the first draft WD for an ontology for the delivery context, where the ontology is decoupled from the APIs that it models. DCCI is a client-side framework, but doesn’t itself define any properties. With a little work, DCCI could be used for:

• dynamic content adaptation on client
• checking battery level, signal strength
• controlling the display brightness
• turning the phone’s vibrator on and off
• checking screen orientation and size
• checking available free memory

The following will need work on trust models and could be part of a second wave, following a security workshop planned for late 2008.

• implementing location-based services
• interface to on-phone applications (PIM)
  including calendar and contacts
• allowing web page scripts to initiate phone calls

It seems timely for the W3C Mobile Web Initiative to create a roadmap for building concensus on client-side access to device capabilities. This seems like something W3C should be taking a leadership position on given the opportunities for third party developers to stimulate mobile data traffic if we succeed in standardizing the APIs. Without such action there is a risk of fragmentation as multiple APIs appear and developers have to choose between them.

What’s the best way to bring together the relevant stake holders? For instance, browser vendors, device vendors, network operators and application developers?

The next goal was to create a cross-browser slide editor. I would like to make it really easy for people to create slides and to avoid the need for them to deal directly with the markup. Internet Explorer introduced a rich text editing feature some years back, which has now been duplicated in most modern desktop browsers. Unfortunately each browser has its own quirks in how it approaches this, but there are work arounds. A much bigger problem for me was that simple rich text editors don’t provide the kind of user interface needed for slides. PowerPoint offers a very different UI for authoring compared to Word.

It rapidly became clear that to approach the ease of use of Power Point, I would have to try something different. After quite a lot of work, I found that I could emulate basic text editing support by using an HTML span element for the editing caret and JavaScript to define the desired behavior in response to different keyboard events. This revealed big variations in how browsers support the keystroke events. For example on Opera, the keys for period and delete produce the same key code. Nonetheless, a bit of hacking sufficed to find a rough work around. I am very much hoping that browsers will add support for the DOM3 text events which provide a well thought out solution for text entry.

Slides without graphics tend to be rather dull. Unfortunately whilst you can get browsers to scale images, this tends to introduce nasty side effects, particularly for line art. The solution is to use vector graphics. W3C has been working on SVG for many years now, and browser support is slowly coming up to speed. Perhaps SVG would be a good basis for presenting and editing slides? SVG 1.2 looks really promising with a well defined DOM (the micro DOM) that includes DOM3 text events. SVG 1.2 supports text wrapping and a means to indicate which fields can be edited when viewing the SVG file. This sounded wonderful after the trials and tribulations with HTML browsers.

To ensure everyone could use the slide editor, I have to work with what the desktop browsers support. Firefox and Opera are still slowly progressing towards full compliance to SVG 1.1, but full support for SVG 1.2 is a long way off. Unfortunately, these browsers offer the HTML DOM and not the SVG microDOM. Luckily, the work arounds for HTML proved to also work for SVG. I now have basic editing support working using a tspan element in place of the span element I used in HTML. There are two versions, one using SVG 1.1 that works in Firefox and Opera, and another using SVG 1.2 that works in the BitFlash SVG viewer.

Given the problems with browser SVG support, it seemed like a good idea to take a look at the potential of the very widely deployed Flash player plugin. This is something that I had been meaning to do for a long while. In addition to the official Flash authoring tools, there are a range of open source tools such as gnash,  swfmill, swftools, and mtasc, that have the advantage for me of running on Linux. I was able to get the Macromedia Flash8 authoring suite trial to run under Wine, but Adobe is no longer selling licenses for Flash8. I haven’t tried CS3 but couldn’t afford it anyway for personal use. The Flash file format (swf) supports rich graphics, event-driven scripts and rich text editing. You can also easily download and parse XML and post the updates back to the server. In principle, Flash looks very attractive as a basis for authoring applications of XML. Some of the drawbacks include the fact that Flash SWF isn’t an open standard e.g. compared to SVG, and concerns about the accessibility of Flash-based applications.

Accessibility features in Flash have improved considerably since earlier versions and Flash content can now be used with screen readers such as JAWS. In some cases it is a mainly a matter of providing text alternatives to graphics. In other cases, an audio narrative can provide an effective alternative to screen readers, but this won’t be adequate for people with visual and hearing impairments, and some form of timed text may be needed. Macromedia published best practices for accessible flash design (PDF) back in 2005. However, there remain problems with tab order and access keys when Flash is used as part of an HTML page. Hopefully future browsers will provide better integration of accessibility information across HTML and Flash.

In the longer term, I am hoping to explore the use of XML for easier ways to author Web applications without having to be concerned over the details of particular delivery environments. Such end-to-end models can be compiled to a range of delivery environments including, HTML, SVG, Flash, Java and .NET. This promises to reduce the cost of developing and maintaining applications, as well as making it easier to attend to security and accessibility concerns. I will give more details in a future blog.

In closing, I am now focusing on using SVG as the basis for the slide editor and there is still a great deal of work to do before I have a slide editor ready for people to try out, but I hope to get there by Summer 2008.