An XML Information Processor

Imagine writing an office system today, with no legacy to hold you back. You might build an XML processor which can handle “unstructured” documents (which have lots of structure, of course, as long as you can recognise it) as XML documents and translate other structured formats (particularly SQL) into XML for processing. The equivalent of Microsoft Office would just fall out on the way, but you’d have a lot more than just Office.

This is more-or-less what JustSystems is offering with xfy, a fundamentally disruptive technology being promoted as “the world’s first XML-based information delivery framework”. We’re not quite sure about that claim – Software AG (for example) has something called tamino that could take the same description – but it is probably true on the desktop (despite Microsoft’s new-found enthusiasm for XML, the OpenXML vs. OpenDoc disputes – see this article and the comments on it – suggest that Microsoft might not use XML quite as others do).

JustSystems itself has a respectable provenance, as it claims to be the largest supplier of desktop technology in Japan (it has a suite of Office products), was founded in 1979 and is only now leaving Japan with its xfy product. Interestingly, it acquired XMetaL (an XML-based authoring and content collaboration tool) in 2006.

Xfy is a data processor not a word processor and can create all sorts of standards-based documentation. Think of it as an XML Browser, instead of a Web Browser. It deals with XML from scratch, from the ground up, and makes use of XML Schema, XSLT and the extensibility of XML. We were talking with Ben Walshaw (Head of Technical Services, Emea, at JustSystems Europe (UK) Ltd) about xfy and he is also fully aware of the semantics issues with XML (XML has no semantics; its tags have no “meaning”, but we assume meanings when we recognise a tag name), unlike some XML gurus we meet, which bodes well for the resilience of xfy-based systems. The semantics issue is important, because making assumptions about the meanings of tags can be misleading when you base decisions on them (and such assumptions break down completely when, for example, an English-speaker meets XML written in Korean). The semantics issue is partly addressed by using domain experts to do the tagging (in a medical document, for example, is “black” a name, a colour, a symptom, an emotional metaphor or a colour-coding) but tagging then becomes a data analysis exercise, with similar political issues and value-add (and it needs a metadata repository to hold the semantic associations).

IBM is very interested in xfy and there’s a close relationship with JustSystems – IBM sees xfy as making “enterprise mashups” visible to users and first partnered with JustSystems to offer a platform for native XML applications at the end of 2004. Xfy has even gained a CTO Innovation Award from IBM. It is worth noting that IBM itself has a long and honourable history in the more sophisticated (knowledge management) aspects of open document processing – it invented SGML, on which XML was based. The IBM relationship may explain why the underlying data repository for xfy is IBM’s DB2 9, which has a pukka XML datatype. Oracle 11g will probably follow, but Walshaw doesn’t seem to have a lot of faith in Microsoft’s handling of XML in SQL Server. JustSystems definitely needs a hybrid SQL/XML database, not just support for XML docs in blobs/clobs (binary or character large objects), although our understanding is that SQL Server does handle native XML these days..

Xfy is an integrating technology that can present technologies with very different “Look and Feel” in a single “Rich Internet Application” (RIA) style of interface. So, to cope with non-Internet data sources, it needs to support RIA outside of the browser – which has the useful additional advantage that disconnected use is supported easily (the last information found is cached and collisions resolved on reconnection). Disconnected use is a bit of an issue with existing RIA applications – such as Silverlight and Flex – although this will probably be addressed, eventually.

Of course, disconnected use brings the problem of several people updating the same information independently and xfy’s collision resolution doesn’t seem to be particularly sophisticated for now. However, full versioning/configuration management is supported (nothing is ever overwritten, according to Walshaw, just marked obsolete) so any issues should be resolvable. Strong audit trails are supported.

Xfy competes with Silverlight and Flex, but it is just about XML, not code – it’s “just” an RIA-style framework for near-real-time applications. It is most effective in (but not limited to) a Java environment, as xfy has a JAVA based client which can combine/unify/normalise and visualise information from multiple sources on the client side without the need for server based scripting. Debuggers are available but everything is built from reusable XML components, so xfy users shouldn’t get into deep, complicated programming-style logic (although nothing is so simple that some techie can’t make it complicated).

So, to summarise, xfy is a new approach to building RIA which produces composite documents based on standard XML and integration via XSLT. It’s a framework for enterprise mashups with role-based visualisation and translation – which “enables” the addition of semantics (meaning) to data (its Roadmap seems to support semantic web in the future) and manages complexity. It features fast deployment, and there’s no expensive XML parsing before data can be used. It is centralised and server-based.

JustSystems’ own internal vision seems to be that “the document is the application” – reminiscent, for us, of IBM’s old OS/2 Opendoc vision (although it also seems to be part of the W3C DOM vision). Jake Sorofman (VP of Marketing North America at JustSystems) says that “JustSystems has the potential to disrupt the document publishing and the application development space. With xfy, the lines blur between these categories. Many processes require the persistence and context of a document and the dynamism and interactivity of a business application. They require structured data to come together with unstructured content-not only on the glass-but as part of a unified document. For many document-centric processes, the document becomes the new application context. We’re no longer making a tradeoff between the live data and interactivity of a business application and the persistence and context of a document”. Perhaps that is, indeed, an idea whose time has come.

However, whether xfy will be successful as it probably deserves to be remains to be seen. The Microsoft Office status quo has a lot of inertia and has its own “office applications” development infrastructure. We think that this has the associated risk of building a “new legacy” forever tying an organisation to Microsoft platforms, despite its use of XML – but it may well be attractive to programmers and organisations that have adopted a “Microsoft strategy”.

Xfy, on the other hand, may be able to exploit the move to open document standards in many government organisations and we think is unlikely to produce any sort of legacy – because it is “just” ordinary XML and associated schemas. We do believe it has a good chance of success but we can really only watch developments for now. However, if you are technically inclined there is an xfy community (which we think is a good sign) with plenty of xfy download possibilities here.