mark-birbeck
Submitted by administrator on Sat, 05/17/2008 - 19:12.
Something which was part of the early design concepts from the XHTML Role Attribute Module, which has got a little lost, is that elements from any language can provide a handy source of role values too.
To reconstruct the logic:
A role value is simply a URI, or resource. The reason for this is so that the extensibility hook that we're creating puts us straight into the world of RDF.
Now, some values of @role will need to be invented. This might be because they simply don't exist, or because we want the values to be 'cross-cutting', and apply to many different mark-up languages.
But there are many values that already exist, that are suitable for use in a variety of situations. For example, XForms has a hint element, that can apply to its form controls:
<xf:input ref="surname">
<xf:label>Surname:</xf:label>
<xf:hint>Please enter your surname or family name</xf:hint>
</xf:input> The semantics of 'XForms hint' and pretty well defined, so it should be straightforward to apply them to other situations. For example, an Ajax library could pick up a hint and do something with it in an (X)HTML document, even without XForms:
<input name="surname" />
<div role="xf:hint">
Please enter your name
</div> SVG
This whole topic came up recently because someone asked whether it would be possible to add some new values for role which would identify paragraphs, sections, headers, and so on, and that could e used in languages like SVG; but the answer is that if we use the XHTML p, section, h1, h2, etc., values then we don't need to invent new roles:
<svg:text role="xh:h1">Metadata</svg:text>
<svg:text role="xh:p">
Metadata is data about data...which is also data...kind of
turtles all the way down...
</svg:text> As you can see, a role-aware voice system would be able to provide feedback to a user in any mark-up language, simply by knowing XHTML role values.
Submitted by administrator on Thu, 05/01/2008 - 12:50.
May is going to be pretty busy with talks about XForms, RDF and RDFa coming up.
First up is my talk XForms, REST, XQuery...and skimming at XTech 2008. The talk embraces themes I've been pursuing for a couple of years now; that as we put more functionality into the client, and servers get 'cleverer', it becomes much easier to build sophisticated web applications. Of course server technologies are moving so fast now that this whole approach is making more and more sense, so I'm looking forward to taking in recent developments in my talk. For example, both Amazon and Google effectively have 'databases in the cloud' that can be used to store data and query it, via APIs, with literally no configuration.
A few weeks later I'm going to be giving a tutorial on RDF at SemTech. This is an interesting development for me, because RDF and the semantic web were always my first interests--before XForms and before XHTML 2. (As well as writing RDF parsers, and designing applications, I also contributed chapters on RDF and RDFS to a couple of books on metadata and XML.)
But one problem I always had when trying to build semantic-web applications was that defining the user interface was pretty hairy. This was partly because RDF Schema is tricky to process, but also because HTML was insufficiently powerful in its core feature-set, so the translation from RDF to HTML involved a lot of work.
The need for a user interface language that was much richer than HTML was therefore why I got involved in the XForms standard (and worked with a team of people to produce the first fully conforming XForms processor, formsPlayer). So although it may not seem directly connected to the semantic web, I believe that in the coming period XForms will start to become a key part of the semantic web's architecture.
Another problem I kept coming up against whilst developing for the semantic web was the difficulty in actually publishing metadata. In particular I always found it frustrating that there was a lot of really useful metadata just sitting in ordinary web pages, and no-one could get at it. Attempting to resolve this problem gave rise to RDFa, and I'm excited that the RDFa in XHTML working draft is extremely close to becoming a stable recommendation. And as interest in RDFa grows, I'm pleased to say that some of my other presentations in May will be 'tech talks' on RDFa at Yahoo!, eBay and Google. (I'm really excited that I might be getting to meet some of the guys behind Yahoo!'s SearchMonkey.)
My final talk of the month will be at the excitingly-named Kings of Code, and I'm looking forward to talking about XHTML, XHTML 2, HTML 5, XAML, and anything else I can think of in relation to web languages.
Submitted by administrator on Sun, 01/20/2008 - 11:05.
I quite like the 'planet' format of community web-site. It essentially consists of an automated site that reads RSS feeds from blogs and news servers on a particular topic -- MySQL, Gnome, Linux, microformats, etc. It's quite an important service within any community, since not only does it provide a useful place to keep up with what's happening, it's also a way for anyone new to get a 'view from 50,000 feet'. (Or metres.)
So I decided to set one up for XForms, motivated partly by the simple need for such a service myself (Google News Alerts doesn't always catch items on source such as Flickr or SlideShare), and partly by the belief that when a company like Yahoo! mentions XForms, people are going to start looking for more information about it, and we need to ensure that it's available.
After much configuring, tweaking and cursing, the site is live, and called Planet XForms. It aggregates a number of XForms-related blogs, as well as various XForms-tagged resources, such as images from Flickr, presentations from SlideShare, videos from YouTube, events from Upcoming, links from Magnolia and del.icio.us, and news from Google. It also provides a Feedburner feed if you want to get the whole lot in your RSS reader.
The idea is that Planet XForms is completely automated, and not tied to any particular company or processor. This means that if you have a product screenshot you want the world to see, you don't need anyone's permission to get it onto the site; just place it on Flickr, tag it with 'xforms', and it will soon show up on Planet XForms. Have a useful tutorial? Just make a YouTube video, or upload your slides to SlideShare, and as long as you don't forget the 'xforms' tag it will quickly be available to the whole XForms community.
If I've missed any sources of data (I'm holding out on Twitter...), or you'd like your blog included, then please do let me know. And I hope that what we have so far proves to be of use to the growing XForms community.
(One last thing is that I must acknowledge the excellent Planet Microformats site, which has a very different feel to it, than the more 'old-fashioned' style used on most of the planet sites that I came across whilst looking for inspiration. Excellent work by Brian Suda.)
Submitted by administrator on Tue, 01/08/2008 - 15:44.
Yahoo! recently announced their entry into the mobile web applications space, with a service that allows applications to be built and hosted using Blueprint, a purpose-built mark-up language based on XForms.
The Blueprint roadmap describes the underlying philosophy:
Much of Blueprint's philosophy and syntax comes from XForms. We opted for a full declarative language because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all. By using declarative syntax, we can encapsulate and hide the scripting specifics. In some cases, the code could run on the phone, in other case, such as XHTML, we can put the logic on our servers. It's the perfect way to deal with the various environments and their capabilities.
At the moment Blueprint is simply converted to XHTML plus JavaScript for delivery to devices, but the mention of XForms gives a clear indication of where they are heading. And given that Google did something similar with the launch of its Google Mashup Language, it all bodes well for a new wave of web applications that won't be built using JavaScript (or even Java and GWT) but will use straightforward, device-independent, mark-up.
Write once, run anywhere, anybody?
For more on why XForms is Ajax on steroids, see:
Submitted by administrator on Fri, 12/14/2007 - 16:51.
I've not yet had a chance to write up my experiences at XML 2007 in Boston last week, but an announcement today by Amazon prompts me to at least summarise one of the talks I did, called XForms, REST, XQuery...skimming. (Slides)
It's a theme I've touched on a little in this blog, and have spoken on before (at an XML UK meeting, last year, and at XTECH 2007, this year), and the idea goes something like this; building web applications by dynamically generating user interfaces that contain data, is awkward, and difficult to maintain. Web services (which includes REST and APP) removes some of the dependency on databases by hiding the data behind a simple abstraction layer--a kind of 'ODBC for the web'--and XQuery takes this further by giving us a standard language to get at the data.
But XForms is the icing on the cake, since it gives us a rich-client language that can be deployed like traditional web applications, yet is one that ensures a clean separation of the data and the user interface.
During the course of the presentation I showed how incredibly easy it is to create an application with XForms, since forms can be first created on the desktop--loading and saving their data from local XML files--before being deployed to any type of web server. By creating static forms that load their own data, rather than the more common model of dynamically generating static files that contain data, we end up with files that are completely agnostic about where they are delivered from. My demonstrations took them from the desktop, to a simple web server, to eXist (an XML database).
But these applications could even run in 'the cloud', with no web-server. That may sound odd, but I could store any of these XForms applications in SVN or Amazon's S3 and they would work as well as if they were in IIS or Apache. This is the ultimate in simple maintenance and future-proofing, since you are no longer reliant on any particular operating system or server-side language...the forms just 'are'.
GData
The final step of my presentation was to take this a little further and show an XForm that interacts with Google's GData; the form is simple, and accepts a longitude, latitude and comment which is then inserted as a row into a Google Spreadsheet, using Atom Publishing Protocol (APP). Another form is then used to retrieve the entire spreadsheet, and each row is used to create a pin on a map.
The great thing about this demonstration is that it shows that not only are our forms now agnostic about where they run--desktop, server-side, S3, etc.--but now the data becomes agnostic; we don't care how the data is stored, all we are concerned about is the protocol used to interact with it.
And crucailly, XForms' ability to get at this data shows that it really is the missing link when it comes to building a new kind of web application.
SimpleDB
But this generalisation about data just took another leap with the announcement today by Amazon of a closed beta called SimpleDB. This will allow programmers to store and query for data in a manner similar to the way that GData works.
By putting data into the cloud, and then using an easily deployed, declarative rich-client language like XForms, it is possible for the architecture of web applications to be altered in a quite fundamental way, in a direction that is completely different to what we're used to.
Submitted by administrator on Tue, 08/28/2007 - 19:23.
A couple of recent discussions in the RDFa and microformat communities concern areas of particular interest to those of us working on Sidewinder, a semantic web applications framework.
The initial discussion is taking place on the microformats lists, and concerns how to allow authors to indicate what actions are available to be performed on items appearing in a document. The second discussion is taking place on the 'RDF in XHTML Task Force' list; this post provides a good summary of some of the issues.
All in all I find these very exciting discussions, because they concern exactly the types of use-case that prompted me to get involved with the XHTML work at the W3C a number of years ago.
This was because I'd been trying to create the kind of flexible user interface that these threads are describing--no doubt just as lots of other people had--and in my own endeavours I ran up against a number of very serious problems that made me conclude that it was pretty much impossible with the technologies available at the time. And since I still haven't seen a convincing solution to the problem of creating extremely flexible user interfaces, I've concluded that the issues I ran up against are of quite a fundamental nature.
Some of the problems that seem to me to be absolutely necessary to solve are:
- an HTML page contains insufficient metadata about what its content 'means', making it difficult to work out what kind of UI constructs to render;
- even were you are able to work out what the data means, HTML is not itself powerful enough to express the kinds of complex user interfaces that you would want to 'bind' to this underlying data;
- and even if you work out what the data means and define complex UI components, you still can't define binding rules that indicate what widget to use with what data;
- the browser offers only one 'paradigm' for interacting with information of interest, whilst we often want to create applications that can make use of the same rich features.
For every problem...
The first problem--that HTML is not 'rich' enough--is now largely solved by RDFa. It has taken quite a long time to get here, but I think the effort that has gone into getting RDFa right is going to be worth it. The key thing that RDFa does is to get RDF into HTML--once you've got that, all sorts of possibilities open up.
The second problem--that it's difficult to define rich user interfaces with only HTML--is largely solved by XForms. That XForms is a solution is currently not obvious to most people so XForms remains peripheral in application development at the moment. Of course it is possible to define widgets using script but it quickly gets very messy. There is also an enormous problem of re-use, in the recursive sense; most Ajax libraries are works of art, but very few can support the kind of complexity we need. Take the example shown here:
Here we have widgets that are made up of other widgets to an arbitrary depth, but the key thing is that the binding mechanism is based on abstractions; it could be the run-time data type or an abstract widget type, and in both cases it means that at any point in the hierarchy a different widget could be swapped in without disturbing anything above or below. This kind of complexity is extremely difficult to achieve with procedural languages. (See also Introduction to custom controls and Understanding the MVC separation.)
The third problem--the use of binding rules to indicate which widget should be connected to what data--is still a little in the air. One part of it we've solved by specifying binding 'rules' using XPath selectors that are data type aware. This means that we can indicate that data of type 'geo location' should have one set of behaviour bound to it, whilst data of type 'time' can have a different type. These are essentially binding stylesheets and I think this is where we can answer the question posed on the RDFa list as to whether it is the author, the end-user or the browser vendor that should be in control of the widgets--the answer is all of them! By allowing users to express binding rules that override those from authors, we can achieve the best of both worlds.
Finally, the problem that the only paradigm we have for interacting with web-based data is 'browsing' is what we are trying to solve with Sidewinder. The ultimate goal is to have a framework that can be used to build any type of internet-facing application, whether web or desktop based. By allowing all applications to make use of the same semantic functionality and the same binding rules we can allow the users themselves to get control of their data and their applications. (See also Web 2.0, Copernicus and Sparticus: Moving the centre of the web.)
Once you have this kind of 'platform' (see Platform 2.0) then things really start to open up. I could build a clock widget using Silverlight, perhaps, and have that appear anywhere that the time data type is used--whether in my messaging client, my email client, my Twitter gadget, my Facebook desktop notification system, and so on. But you might choose a clock built using SVG, whilst someone else might decide to have a clock that speaks. But any of us could swap one of these behaviours for another at will, for a component we have created or one that we have downloaded from elsewhere--the ultimate, flexible, programming platform.
Submitted by administrator on Wed, 08/22/2007 - 08:42.
The XHTML.com site have published the first part of a two part series on what might be wrong with the web, and how we might fix it. The idea is that the first part consists of short opinion pieces by people involved in various ways with the web, and the second part is a collection of responses from anyone who wants to send something in.
Contributors are Chris Wilson, Daniel Glazman, Joe Clark, Doug Geoffray, Roberto Scano, Jeffrey Veen, Dave Raggett, Mike Andrews, James Pearce, Nova Spivack and myself.
In my comments I focused on the need for a better way to create standards:
I actually have a very positive view of the transition to the 'future Web', and I see many of the things that one might say we need for a better Web already emerging. For example, we need the differences between browsers to be removed, but due to the high quality of libraries such as YUI, Dojo, and Prototype this is well underway. We also need there to be a convergence of application development techniques, so that the same languages can be used for the Web, desktop applications, gadgets, widgets, and so on; but with an explosion of interest in HTML, JavaScript and XForms--as well as the appearance of multi-language platforms like Silverlight--this trend also looks set to continue.
So whilst I might say that these things are crucial to the future of the Web, they are also very much underway, and barring a collective overnight loss of memory by the development community, look certain to continue. But there is one thing that to me doesn't look so assured, and that is whether standards are agreed upon around Ajax, and more generally, the whole approach to standards development.
In general, standards (at least those from the W3C) are developed in a kind of 'kitchen-sink' style, where some specification tries to include just about everything that can be devised on a particular topic--and therefore takes years to write. A good example is SVG, and even, to some extent, my own favourite, XForms. In both cases there are many useful things that could be factored out of these specifications to be made available elsewhere as smaller, more manageable components, but it is only recently that this approach has started to be tried. Good examples of the 'bite-size' approach are the 'role attribute', 'access', and RDFa, which provide techniques for adding metadata to web documents as well as making them more accessible. (See also The XHTML role attribute: small and perfectly formed and Using RDFa in XHTML 1.)
A good measure that some are learning that this is a promising approach to writing specifications is the backplane initiative at the W3C. But unfortunately, an illustration that lessons haven't been learned is the W3C's embracing of HTML 5, which is not only a case study in kitchen-sink design--let's throw everything in there--but a case study too of the problems caused by the 'not invented here' mindset.
If the W3C continues to support the creation of enormous specifications that take years rather than months to complete, then it will almost certainly become increasingly irrelevant to the 'future Web'. Of course, based on the W3C's lack of coherent leadership around the whole HTML 5 question, some might not see that as necessarily a bad thing, but it does raise the question as to whether other organisations can fill the space with a better process. For example, can the Open Ajax Alliance take a much more focused approach to standards writing, creating small specifications that can be easily combined? If so, it's possible that the vacuum would be filled, and the future of the 'future Web' would stand on a firmer footing.
Whilst I'm not quite sure where the future of standards creation will come from, the sheer dynamism we see in the Web development space makes me certain that it is imminent. If we can devote even a fraction of that creative energy to evolving a new approach to standards development, the future of the 'future Web' looks very bright indeed. But if we don't, then for the foreseeable future we are looking at increasing fragmentation, and the lack of standardisation in the browser merely being transferred to a 'lack of standardisation in the libraries'.
Anyone is free to respond to the discussion, which needs to be done by September 10th. They'll then use the responses to create 'part 2'.
Submitted by administrator on Tue, 07/17/2007 - 10:35.
Progressive enhancement is an approach to web development that has been around for a few years now. (More on PE at Wikipedia.) At its most basic it suggests building our web pages in a 'clean' and uncluttered way, and then layering functionality onto the mark-up using various mechanisms, such as stylesheets and scripts. The idea is that browsers without the additional capabilities can still render the page in some fashion, but those with additional power--such as scripting support--can add more enhanced features.
This principle actually underpins much of the work we've been doing on XHTML 2, which has involved taking HTML back to its semantic roots. In particular the work on RDFa has been to a large extent motivated by providing more semantic 'hooks' on which to attach increasingly focused functionality. (The work pre-dates the term progressive enhancement, so it isn't generally called that.)
But there is a new phenomena afoot, which I'd like to call progressive browser enhancement. It's something we've been doing for a while with our work on XForms and formsPlayer, but it also has wider applicability.
DOM Events and standards
To illustrate the idea of PBE, let's look at eventing in the browser. Many Ajax libraries have their own eventing architecture, and they are without exception non-standard. This is a shame, since the W3C has a standard for DOM events (DOM 2 Events) which has been around for years and is very clearly defined. Of course, part of the problem is that whilst it has been implemented in Firefox, Safari and Opera, it's not available in Internet Explorer. This meant that when we began our work on formsPlayer, our XForms processor plug-in for Internet Explorer, we had to implement a DOM 2 Events component ourselves.
This does however mean that DOM 2 Events support is potentially available for all browsers, but of course the problem now is that in order to make use of it on IE, people would have to install formsPlayer. And even if we made the module available separately (which we will be doing shortly), the problem for the programmer is that they can't assume that it is installed; there is still an annoying rift between those who have browsers with DOM 2 Events support, and those that don't.
Using JavaScript to enhance the browser
To fill the gap we simply implemented a DOM 2 Events library in JavaScript. Whilst most Ajax libraries went the route of creating their own non-standard eventing architectures, we went the other way and implemented the standard. The advantage of our approach is that if our end-user is running a browser with reasonable standards support such as Firefox, Opera or Safari, they'll get native support for DOM 2 Events, and hopefully a faster experience. Similarly, if our user is on IE and has installed the formsPlayer DOM 2 Events component, they will likewise get a faster experience. It's only the middle group using the scripted version of DOM 2 Events who will have a slightly slower experience.
But the key point is that the end-user now has some control, since they can add a DOM 2 Event component if they want to--most likely as part of some other package--independent of the actual web applications they are using. And for the authors of web applications life is much easier, since they are coding to a standard, rather than being forced to code to the specific event architecture of YUI, Dojo, or whatever Ajax library they want to use.
This is the key idea of progressive browser enhancement.
Threading in Google Gears
Another example of PBE is threading in Google Gears. There are a number of JavaScript libraries around that create simple threading by using the timer in JavaScript. This is fine for a lot of uses but can affect performance. However, we can follow the same approach as I described above for DOM 2 Events; if the function calls that the programmer makes to create a thread are 'standard', then although in normal operation the less-efficient JavaScript version would be used, with no change to the code the web application can take advantage of 'proper' threading, should a user have Google Gears installed. (See also: Ajax makes browser choice irrelevant...but we still need standards.)
Of course, most users are unlikely to be looking for a threading library to install, just as they will not be downloading a DOM 2 Events module. But if these components are small enough to be bundled up with other pieces of software they will gradually find their way onto users machines as part of other, useful, packages.
However the distribution takes place, it's the end-users of our web applications that are in control of progressively enhancing their browser, not the web application programmers themselves.
These principles have underpinned the design of Yowl, a centralised notification system for web applications.
Yowl centralised notification system
Yowl is a way of providing notifications to users of web applications, but in a way that the user themselves can control. It was inspired by Growl, which runs on the Mac, and which is used by applications such as Skype and Adium; by passing all notifications through a central system users are given the power to decide which messages they are interested in, and how they want to see--or even hear--them.
Progressive browser enhancement allows Yowl notifications to make use of advanced features in the browser if they are available, but to fall back to basic notifications if not. For example, we've created a Windows component that allows messages to be displayed above the system tray. The component is invoked and called from script, and works with both Firefox and Internet Explorer:
However, if the systray component is not installed, the Yowl notification system will simply use JavaScript to show messages within the browser window. You can see a sample of the non-enhanced notifications here--it will run in all the major browsers:
The programmer need change nothing in their code to make use of the systray component if it is present, since as with the DOM 2 Events example, or Google Gears and threading, the user is in control of the browser enhancement, not the programmer.
(For more on Yowl see the Yowl open source project page, Yowl: Design principles and how to use it and Yowl: An open source centralised notification system.)
Where does this leave the browser?
There is still plenty of scope for the browser to evolve and make available the kind of features we're talking about here. But the truth is that progressive browser enhancement makes browser evolution far less significant than it has been until now. That's probably not a bad thing, given the chaos that is currently surrounding the development of HTML since the W3C gave its support to HTML 5; the spec itself is becoming increasingly top-heavy, and bears little relationship to the early principles of HTML. Far from having enormous 'kitchen-sink' specifications, PBE looks to add new features in a more nimble way, via small and focused modules.
Submitted by administrator on Tue, 07/10/2007 - 09:14.
Peter Korn at Sun has obviously decided that there is some mileage in promoting the idea that Microsoft's Open XML Formats is not very accessible. Fine. You can never have too much accessibility, so I'm not going to get upset about that. But in the process Peter believes it worth pointing out that Microsoft don't hold to standards:
In addition to these important questions [lack of accessibility], this white paper nicely sidesteps what I believe is the intent of WGAG 1.0's Guideline 11: "Using W3C technologies and guidelines", and most specifically checkpoint 11.1 "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported." Unlike ODF, MSOXML makes almost no use of existing W3C standards. Instead of using the W3C XForms specification for embedded forms, it invents its own XML terminology for forms. Instead of using the SVG specification for vector graphics, it uses its own vector graphics encoding. Instead of using the MathML specification for mathematical equations, it uses its own math encoding.
All true, of course...all true.
But I've spent a few years in and around the W3C (as an invited expert in the XForms Working Group and the XHTML Working Group), and I've seen up close how all the big companies pick up and drop one or other standard as it suits them, so I can't really take Peter's points that seriously. Much like the idea of open source, standards are a great thing--and much like with open source they become a site for politics and marketing. So as you'd expect, Gray Norton--the main target of Peter's ire--is not about to miss an opportunity to have a dig back, so in his reply on Peter's blog he points out that MSOXML is not the only format not making use of other standards:
Speaking of PDF, would you mind please pointing out the list of W3C recommendations supported by PDF/X-1a, PDF/X-3 and PDF/A? It’s been a few years, but I don’t recall the use of XForms, SVG or MathML in these specifications. These are all ISO standards today, so I’m curious to compare this with the ODF example you cited in your post.
Once again, that's true enough.
I have no interest in taking sides here, but it does annoy me that it's taken for granted that the world is made up of Microsoft who flout standards, and everyone else who doesn't. It's particularly ironic in this example since Gray needn't have gone as far afield as PDF to point out lack of XForms support--he could have looked at ODF itself. Whilst the Open Document Format may well have adopted the XForms model, they've not used any of the form controls. And worse, some of the bindings they have used to connect the controls to the model are non-standard (they've made buttons bind to submissions, rather than model data).
But I'm not at all criticising ODF for this; what does it matter if only some part of XForms is adopted today in ODF? If it does the job then that's great. If there is any positive criticism to level it would be at the XForms standard itself for being insufficiently modular to facilitate its use in other formats.
In short, when everyone is at the same game of promoting one or other standard for commercial or political mileage, it's worth trying to read between the lines a little. Which leaves us only one basis on which to judge any standard--whether it is actually any good for the task at hand.
Submitted by administrator on Tue, 06/19/2007 - 22:05.
So Hackday was certainly an excellent event.
If you weren't there and have only heard about lightening striking the building (no, really), then it may sound odd to say that it was 'excellent'. After all, the lightening caused problems with the wi-fi, and it didn't really settle down until quite late in the day. And it also caused something far more surreal...the windows in the roof opened just at the moment it started raining, so we had to be evacuated from the main hall. But the organisers coped with all of this in such a calm way that you couldn't help but get into the swing of things, and keep on adapting.
However, the upshot was that I 'adapted' to the point of avoiding doing any hack that required the Yahoo! APIs, since you had no idea whether the network would remain up for more than ten minutes. Instead I decided to implement something I'd been mulling over for quite a while, and that's a browser-based implementation of Growl.
(If you want to cut straight to a demo, it's available by selecting "Try it now" from the Yowl project page. It's been tested with Firefox, Safari and IE, although the latter does not yet have proper opacity.)
Growl
Growl is an interesting piece of software for Mac OS, which centralises the management of notifications. The idea is simply that applications such as Skype or Adium ask Growl to display a message, rather than doing it themselves. However, this makes it sound like just a standard library which might save you writing a bit of code, but Growl is much more important than that. Since all messages pass through it, it can provide facilities to enable the user to indicate whether a message is enabled or disabled, to control how they appear, for how long, and so on.
But even that doesn't capture it all; extensions to Growl provide different types of notifications, which are not limited to the display. For example, a user can request that certain messages are spoken to them, or even emailed.
formsPlayer messaging
We have a module in formsPlayer, our XForms processor that handles XForms messages, and it provides the ability to speak (as long as Microsoft Agent is installed on the PC). Our module also allows authors to display XForms messages as system tray messages, so breaking out of the confines of the browser window.
So we've long harboured a desire to break this component out into a standalone module that could be used in other applications, and at the same time provide extra features like a debug message logging mode, and so on.
But an idea that started to form recently was for authors to be able to make a single call to an API requesting a message, and for that call to either be handled in script if formsPlayer was not installed, and handled by the formsPlayer messaging module if it was. This would mean that authors can get richer messaging functionality if it's available, without having to change their code.
YUI-based notifications
So for Hackday, I decided to implement the first part of this, and used the Yahoo! User Interface Library (YUI) to provide the core notification code. I created a set of interfaces that quite closely mirror the Growl interfaces and object structure, and since my code uses the Yahoo! library, I decided to call the library Yowl.
The library displays notifications based on a combination of individual settings and themes. One interesting feature I added was to store these themes in a Google spreadsheet, and retrieve them as JSON--all of which continues the idea of 'programming against the cloud' that I've been calling 'skimming'.
You can try the current state of the library on Firefox, IE or Safari by selecting "Try it now" from the Yowl project page. Note that depending when you try this, the IE version might not have opacity support.
Next steps
Various features will be added this week, mainly based on making use of additional functionality if available. For example, it will be possible to save your preferences for different web applications, in Google Gears if it's installed. Similarly, if the platform has formsPlayer and Microsoft Agent installed then spoken messages will be available on Windows. One particularly interesting goal is to make use of Growl itself if it's detected.
Once the library is suitably advanced, we'll also fold it back into formsPlayer, and it will become our core messaging module. The interfaces will also be written up separately since they provide a key module of the XForms backplane.
Submitted by administrator on Fri, 06/15/2007 - 19:16.
 So tomorrow morning it's off to Alexandra Palace for the start of Hack Day London. My wife is raising an eyebrow as I ready my sleeping-bag, and she may have a point...but I'm secretly quite looking forward to hanging out with a lot of smart people, hearing about their good ideas, with no-one around to tell me what time to go to bed.
For myself, I'm hoping to get involved in projects relating to metadata and rich-clients. I'm sure there will be people working in this area, but if not, I've got plenty of new things we've been experimenting with that I might be able to get others to take a look at.
RDFa Parsing
Perhaps the most interesting is the use of our RDFa parser within a blog or other document. By adding metadata to elements in a document you are providing a hook which gives you more information about some item. Onto this hook you can 'hang' further functionality or more information.
To illustrate, let's say I have a cookery blog on which I mentioned Canteen Cuisine by Marco Pierre White. Given that I probably want to make some money from the site with my Google Ads and reseller links, I will most likely place a link to a site like Amazon around the words "Canteen Cuisine":
I found a good recipe in <a href="http://www.amazon.com/gp/product/0091808189?ie=UTF8&tag=escuelerie-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=0091808189">
Canteen Cuisine
</a> which you really should buy so that I get a kick-back. Obviously this satisfies my commercial yearnings, but it doesn't really contribute to the great 'mass' of semantic information that others might find useful. It doesn't actually tell you which book is being referred to, only that there is a link to a page on Amazon. It would be far better--and easier, as it happens--to simply tag the book with an ISBN number, and leave the creation of links to Amazon, or Barnes and Noble, to some other layer of behaviour.
The key is to use RDFa to indicate a unique identifier for the book, and also to indicate an object type, i.e., to indicate that the item we're dealing with is really a book:
I found a good recipe in <span xmlns:bib="http://somebig.org/" about="urn:ISBN:0091808189" class="bib:book">
Canteen Cuisine
</span> which you really should buy so that I get a kick-back. If you know RDF then you'll understand that the generated triples are:
<urn:ISBN:0091808189> rdf:type <http://somebig.org/book> . If you don't know RDF don't worry; the main point is that we've added mark-up that says nothing more than:
"urn:ISBN:0091808189" represents a book. But that simple fact is pretty useful, since now we could use the ISBN number to go and get more information from Amazon, and then display the data in a tooltip, or add links so that a reader of the cookery blog could buy the book or add it to their wish-list.
Before we look at how we get that data, it's worth pointing out that Amazon does offer the Quick Linker widget for TypePad users, but you'll see that the mark-up looks very strange:
<a type=amzn asin=B000012345>I love this item</a> In some ways it's similar to what I've shown with RDFa, where we use a small amount of mark-up as a hook to generate richer functionality, but in their case it's an Amazon-specific solution. A key design goal of RDFa is to provide a generic solution that would work with all types of data.
RDFa action handlers
Once the RDFa parser has 'found' items in the page it then does something with them. Up until now all of our experiments have been to simply display data in a different way, such as showing FOAF information as a card with the person's picture, or event information as a pin on a map. The Operator Firefox extension (which now supports RDFa as well as microformats) takes a slightly different approach and allows the user to do things with the data, such as add an hCard to their contacts database.
The Amazon book experiment is a first step towards combining these approaches. The action handler that gets run when a book is found actually goes to get further data about the book from Amazon, before it shows a panel that contains an image of the book and its title. This means that we don't need to know any URLs for the book on Amazon or where its images are located, since they are derived in the action handler; all we need is the ISBN number.
Yahoo! Pipes
But an interesting twist here is that we don't go directly to Amazon to get the data, but instead go via Yahoo! Pipes. There are many reasons for doing this--not least that it fits well with my ideas about skimming--but the main one is simply because Pipes gives us JSON data for any feed we can access, which works nicely with the model we're building here. By running all of our data requests through Pipes we can provide a single format to our RDFa processor, even if we decide to change the source of our data at some later point, or add further services into the pipe to add more metadata.
The pipe that we've defined for Amazon actually takes the URI of the ISBN number (such as urn:ISBN:0091808189) rather than just the ISBN number, because at some point I'd like this to be a proper RDF query. So I'm actually saying, "give me everything you know about this URI", and whilst that URI currently represents a book, in the future the same query might be able to return information about URIs that represent people, ships, planets, and so on.
What's next?
Everything we've been working on so far is about providing a solid widget framework that can be used to enhance any page on any site, in a simple and consistent way. I'm sure that at Hack Day there will be people working on ideas to do with enhancing blogs, ideas related to using the semantic web, microformats (whether in the traditional or RDFa style), and many other things besides, and so I'm really hoping that this will be an opportunity to move some of this work on, in the context of real applications that people want to build.
Submitted by administrator on Tue, 05/01/2007 - 15:51.
For me, one of the most exciting developments on the web in recent years has been the growth in services that let you manage raw data. Many of the most useful such services originate when some web-based application--such as Google calendars or spreadsheets--exposes the underlying data. For example, with Google Spreadsheets, it's possible to use ATOM to query spreadsheets for certain values, or add rows and columns, making this a very powerful way of storing data 'in the cloud'. (See Web 2.0, Copernicus and Spartacus: Moving the centre of the web.)
We're building quite a few XForms applications that make full use of this power, and it's something I'll be talking about at XTech 2007, in my session XForms, REST, XQuery...and skimming. Since the approach we use could work on any XForms processor, talking to any ATOM-based server, we've decided to create an open source project to host the forms, and document their use. If this is an area of interest to you, check out the GData XForms client project on Google Code, and its discussion forum.
Submitted by administrator on Mon, 04/09/2007 - 12:02.
An interesting question has been raised on Linkedin Answers:
What is your opinion of formsPlayer, the XForms development environment, with regards to developing dynamically configurable UIs where throughput is critical?
Although phrased as a question about formsPlayer, it gets to the heart of important issues that concern XForms, so it's worth seeing this as a collection of separate but interrelated questions. The first question is essentially about how appropriate XForms is for developing dynamically configurable UIs, whilst the second relates to whether there are performance issues to watch out for. Having established whether XForms is suitable, the third question asks if formsPlayer specifically, is right for the job.
Since solving the problem of dynamic user interfaces is exactly the reason I got involved in XForms in its early days, this was bound to be a question I'd have an interest in, even if it hadn't mentioned formsPlayer.
Dynamic user interfaces
A number of years ago much of my work was based around content-management systems. Although my company built a number of different applications and took a number of different approaches to the problem, the common factor in everything we were investigating was the desire to create flexible user interfaces. We nearly always came up against the limitations of HTML in what we were doing, and as a result we nearly always found ourselves defining user interfaces in some hacked together UI language...until one day I stumbled across XForms.
XForms as a UI definition language
Initially we simply used XForms to define user interfaces, which were then translated into HTML. XForms was perfect for the job because it allowed UIs to be defined in an 'abstract' way, independent of any platform or system. This was important because other languages that could be used--such as XUL--were insufficiently abstract and focused too much on GUIs. (And although HTML is to some extent abstract, it just doesn't provide enough of a feature-set.)
In some ways both of these problems had already been overcome by defining our own intermediate forms language, but XForms was not only more powerful, it came from the W3C, and we felt it important to use standards (standards often lead to productivity benefits).
XForms as a run-time language
Of course it wasn't long before we decided that passing XForms through an XSLT processor in order to produce static HTML was nowhere near as interesting as processing XForms at run-time, and we decided to spend some time producing a run-time processor. We worked on a number of different architectures, all of which were useful in different contexts, but the one we decided to put most effort into was our browser extension, formsPlayer.
By putting XForms into the browser we were able to speed up our form development times (edit your form and press F5), as well as improve performance and the range of features that we could support. Other developers took other routes, and now, a few years on, there are a wide range of XForms processors, each reflecting a different approach to the architecture, and encompassing a variety of platforms; there are solutions for mobile devices (PicoForms and MoviForms), browser extensions for both Internet Explorer and Firefox (Mozilla XForms and formsPlayer), and of course sophisticated server-side transformation engines (Orbeon and Chiba).
(XForms processors can be built with such a broad range of architectures because of XForms' MVC structure, which I hope to discuss in another post.)
XForms and performance
Whilst it's clear that XForms is an ideal solution for dynamic UIs, it has to be said that it is not (yet) a silver bullet that will hide issues with the underlying architecture. Just as when building an ASP, JSP, Rails--or whatever--solution you need to get your architectural approach right for the task at hand, so too with XForms. Issues such as getting the right data at the right time, or creating modular and manageable forms, will still need to be taken into account.
One problem we see a lot in our consultancy work is that XForms gets treated as a programming language like Visual Basic, rather than a web-based technology. As a consequence, authors tend to create very large forms, often with numerous instances each importing a large amount of data on document load. This is often compounded by using XSLT to generate the forms, creating a great deal of avoidable duplication, and resulting in even larger forms.
These are not practices that an Ajax, Java or C++ programmer would follow whilst building an application, but because XForms is so powerful, it presents a great temptation to the author to create monolithic forms without consideration to what is going on 'under the hood'.
HTTP and concurrent requests
For example, most Ajax programmers--at least those who program to the metal--will tell you that there is no point in sending more than two concurrent HTTP requests to the same server, since the third and subsequent requests will be blocked by the browser until the first or second completes. This is not a browser limitation, but a consequence of the HTTP specification, and the effect is to slow down the loading of the main document if all the required images, stylesheets and scripts are placed on the same server.
If you look at Google Maps or Flickr, for example, you'll see that the image URLs make reference to lots of different servers; you may have assumed that this is to do with distributing server load, but it's not (that problem can be addressed in other ways), and is in fact to do with finding a way to allow browsers to load more external files at the same time, and so improve overall load time. If all Flickr images or Google map tiles were stored on one server then the elapsed time for loading four images into your browser would be the amount of time taken to load two images, one after the other. (I.e., two are loaded simultaneously, followed by another two.) But if those four images were each on separate servers, all four could be requested at the same time, and the elapsed time would essentially be halved.
Unfortunately, although XForms hides a lot of complexity from the author, this is the kind of thing that XForms can do nothing about--it won't matter what XForms architecture you use if the transport protocol is HTTP. This means that if you have a number of instances in your form, each loaded via the src attribute, the initial load time will be limited by the fact that only two instances can be loaded simultaneously. And since the UI won't usually be available to the user until all models are initialised, this could create a bad experience for the user.
Of course the good news is that XForms handles data communications asynchronously out of the box, which means that once the data has been obtained, any form controls that depend on that data will automatically be adjusted to reflect any new values. So provided that you get the underlying architecture of your application right, managing XForms itself is very straightforward.
Deferred loading (or 'Google Suggest')
Another common problem caused by XForms making some things just too easy, concerns very large selection lists. In XForms it's straightforward to populate a select1 from some XML data, by using the itemset element. The problem is that authors will often load the necessary instance data when the form first loads--well before it is ever needed--and worse, this data could be quite large.
Once again it's important to think about the principles we would have applied if we were writing a C++ or Java application--or even an Ajax one--that was going to obtain data from the internet. For a start we would probably consider loading the data only at the point when we needed it, or perhaps in the background, and in many situations we'd certainly try to load only as much information as was needed.
For example, if we have a large list of chemical compounds or part numbers for a car, there may be thousands or even tens of thousands to choose from. But by connecting a select1 to an instance that is populated with data from the server as the user types--as popularised by Google Suggest--we don't need to download so much data, and we also reduce the size of the list. (See XForms Patterns: Incremental and 'Google Suggest' and Using Google Suggest to Categorise del.icio.us for a detailed discussion of how this is done.)
XForms modularisation
None of this is to say that there are no problems with XForms, and that the only issues you'll ever have are to do with the underlying infrastructure, and as XForms is used for larger and more ambitious applications, there is a lot of scope for improvement at the mark-up level. For example, not only could we defer the loading of some of the data (as discussed above), but we could also defer the loading of some of the form. There is no mechanism in XForms for doing this at the moment, but much of the 'machinery' is in place in XForms 1.1, and it could be quite straightforward. (See Using subforms in XForms for some ideas on this.)
formsPlayer
The final question being asked is simply that if the first two questions are answered positively--i.e., if XForms is a good technology fit in applications that need responsive, dynamic forms--is formsPlayer a good choice as an XForms technology?
The answer to that question will depend completely on the architecture being deployed to, since as we've seen, XForms can be used in many different kinds of environments. For example, Chiba and Orbeon are both great server-side solutions. They work by translating XForms into HTML (or HTML plus Ajax) that can be processed by any browser. The key benefit of using XForms in this way is that it abstracts away much of the logic that would normally be trapped in RoR controllers, ASP scripts, Java servlets, and so on.
formsPlayer on the other hand, pushes all of the processing into the client, which has advantages when it comes to control over advanced functionality (we are able to do things that browsers cannot, such as save-and-resume, off-line working, PDF printing, and so on), but for the time being we only support Internet Explorer on Windows (although versions for other platforms are now being developed).
An interesting bonus of having full XForms support in the client, is that formsPlayer can be deployed not just in web-based applications as you might expect, but also embedded in other kinds of applications. For example, we have a customer that uses fP inside a .NET application that runs on Tablet PCs; this architecture allows them to use more conventional programming techniques for their processing logic (in this case C#), but to use simple XML tools to develop the complex user interfaces that are needed in their industry. In other words, they use XForms to give them more "dynamically configurable UIs" than C# is able to.
(It's worth noting that this is a real problem for everyone, and to some extent it lies behind the motivation for XAML. But in my view, XForms wins over XAML by being a standard.)
formsPlayer therefore meets a different set of needs to server-side solutions like Chiba and Orbeon, so as with any application, developers will need to work out for themselves which XForms architecture is the most appropriate for their project.
Regardless of the model used, it should be stressed that we are still dealing with only one language. Try finding another programming language which would allow you to write an application that could run in a browser or embedded in a .NET application or on a mobile phone...or even as a server-based application, without altering any of the code.
Submitted by administrator on Mon, 03/26/2007 - 12:11.
If you use Selenium for your web application testing, then you'll already know how useful it is to be able to automate tests. To get the same ease of testing for XForms applications we recently added some properties to formsPlayer so that Selenium scripts can make assertions against the values inside a running XForm. We've also created the necessary Selenium extensions to provide access to these properties from within tests.
A description of how it works, guidance on how to write tests, and links to the Selenium extensions, are all on our site, under Using Selenium to test XForms and formsPlayer.
Submitted by administrator on Tue, 03/20/2007 - 10:21.
Adriaan de Jonge's article XForms vs. Ruby on Rails is a must-read for anyone interested in XForms.
You may not agree with all of it, but the author clearly understands the benefits of XForms, even if he ultimately comes down on the side of Ruby on Rails. And he makes some interesting suggestions as to where XForms should be going next.
The following quote is a useful summary of both the power of XForms, and the things we need to focus on to allow it to be used by more and more people:
XForms logic beats any other technique when used in XML documents with semi-structured nature. XForms logic is based on XML specifications and XPath queries. This notation requires a thorough understanding of XML, creativity with XPath, trial and error, and great talent for logical puzzles. For someone with the knowledge and experience of a software architect, the simple tools in XForms can be the building blocks of a very advanced and intelligent application.
Submitted by administrator on Wed, 03/14/2007 - 22:01.
T. V. Raman, one of the key architects of XForms, invited me to do a Tech Talk at Google. The talk was on Monday, and looked at Sidewinder and our approach to using web languages to create desktop applications--XHTML, XForms, RDFa and so on. Although I really enjoyed doing the talk and having the opportunity to explain at length to a load of techies what exactly it is that we're doing, my overriding memory is already that of the lunch afterwards. Unfortunately, the lunch was not captured on video, although they do record the tech talks:
The abstract for the talk was as follows:
Web applications use HTTP to communicate with relevant services and manifest their user ... all » interface via HTML, CSS and JavaScript. With the advent of different gadget frameworks, they have finally broken free of the shackles of the Web browser to manifest themselves on the user's desktop as first-class productivity tools.
In this talk I'll describe Sidewinder, a framework for authoring and deploying web applications that are created as first-class desktop citizens. Applications created in this framework can not only communicate with the web, but with each other, turning the whole platform into a powerful tool for creating mashup applications. Sidewinder can also turn any other web application into a desktop application, such as GCal, KoolIM, Google Docs, and so on.
Another powerful aspect of the Sidewinder framework is the ability to display custom widgets based on the type of the data being processed--chosen dynamically at run-time. This kind of flexibility is crucial when building desktop mash-ups based on varying sources of web-based information, and Sidewinder goes further by making it easy to process the data-oriented web--including microformats and RDFa.
The presentation will include a number of rich internet applications that use the Sidewinder framework.
Submitted by administrator on Sun, 02/25/2007 - 22:07.
A new draft of XForms 1.1 was made available last week. It's a last call working draft, which means that once comments made on the document have been taken into account, it will hopefully be possible to advance the specification through candidate recommendation, and on to a full recommendation.
To be brutally honest, in terms of features, XForms 1.1 is nothing to write home about. The bulk of the new stuff was needed long ago, and we could have done with having it in there before now: looping and conditional constructs are crucial to any language; the ability to set URLs and headers at run-time is a 'must-have' when using SOAP, WebDAV, ATOM, and REST; and being unable to insert nodes into a nodeset when all the nodes had been deleted was painful! Thankfully, those days are now behind us. :)
But just because none of these features are unanticipated, doesn't mean that this document is not an important one.
For a start, in many places it's clearer than XForms 1.0; although W3C documents are always a team effort, the improving coherence is due to a lot of hard work from John Boyer, as he's often prepared to go the extra mile when writing an explanation or giving additional examples. (A sense of what has changed can be seen by looking at the version with all differences highlighted.)
Secondly, whilst I might have a moan that the new features were slow coming, the point is that they indicate the commitment on the part of the working group to solve real world problems, and more importantly, they show how the underlying XForms architecture easily lends itself to the addition of new features in a natural way.
And finally, with the new submission features of version 1.1, and the already powerful XML-handling that was a hallmark of version 1.0, XForms becomes the obvious choice for quickly creating rich internet applications that use ATOM, WebDAV, and REST. That XForms does 'come of age' is crucial if, alongside the proprietary offerings of Adobe and Microsoft, there is to be an approach to building internet applications that is based purely on open standards.
Submitted by administrator on Fri, 02/23/2007 - 16:56.
 No, last-night's mashup* wasn't really a punch-up...but we did have a thoroughly enjoyable ding-dong on topics ranging from whether the next wave of the web would be sensual or semantic, whether rules-engines were the answer to our problems, whether placing a red cross (or a green tick) against an entry in search results was providing a service or 'policing the web', and much more besides. Combined with a great venue, and some interesting characters to share a bottle of beer with, it made for an enjoyable and interesting evening.
Although the meeting was 'about' the semantic web, organiser Sam Sethi was keen to avoid yet another discussion that remained high-level and abstract, and instead wanted to look at some of the exciting things that can be done once you get your hands on the data. Of course that didn't stop some people from trying to explain what 'semantic web' means, and unfortunately they did so with just enough clarity to convince everyone else that it was an unrealisable pipe-dream.
All of which indicated to me, at least, that Sam had been right when he made the decision to focus the evening on what can be done today. As part of illustrating this, he kicked off with some nice demos of the Firefox extensions Webcards and Tails, both of which process microformats located in the ordinary pages you view whilst you are browsing...and both of which look great.
My demo also involved a browser extension, this time for Internet Explorer, and one we created ourselves using the browser extension features of formsPlayer. The data I used for my demonstration used the RDFa format rather than microformats, and to illustrate what the sidebar can do I used Ivan Herman's home-page (which contains FOAF information) as well as my previous blog entry describing the mashup* event (which contains FOAF and iCal information).
The RDFa browser extension simply parses the HTML document in the main window, and stores any RDFa it finds. Then, using XForms and formsPlayer's ability to render custom widgets based on the datatype of the data, the information from the document is displayed in ways that are specific to each piece of data.
In the case of the mashup* event we have two high-level widgets, one for a person and one for an event. The person widget simply shows a person's name, a link to their email address, and their picture. The event widget shows the title of the event, a link to any further information about the event, a map of the location, and the time the event starts. Both the map and the clock are of course themselves widgets--the first an interactive Google Map, and the second an analogue clock created using SVG:
The architecture of this sidebar is interesting for two reasons; the first is that it allows different actions to be performed depending on the data that has been located, and is something that Tails and Operator allow. But we get further flexibility in our RDFa sidebar when it comes to rendering this information; by allowing the widgets to be selected at run-time, based on the 'type' of the data being shown, we really play to the de-centred nature of the web, and allow users to do what they want with the data that they discover. We need this because RDFa is a generic language, and as such we don't know whether it will be used to carry information about people, events, chemical compounds, items for sale, and so on. But precisely because it's generic we don't need to write a parser for every possible language--we only need one. By allowing different widgets to be displayed depending on the 'type' of the data, we can easily create views on the data that are appropriate to different groups and users.
I resisted the temptation last night to try to explain what 'semantic web' means, so I certainly won't bother trying to do it now. Last night's event convinced me that Sam was right to focus on what we can do with all of this, and the exciting collection of demonstrations makes me think that today, the 'doing' part is making the whole thing feel very real indeed.
Submitted by administrator on Mon, 02/19/2007 - 12:07.
I've been working with Shane McCarron from the HTML Working Group on a number of different documents lately, and it's great to see them made publicly available recently. The first is a new draft of XML Events 2.0, and the second is a new version of XHTML Modularization.
XML Events 2.0
The new draft of XML Events has features that are specifically geared towards future versions of XForms and compound document mark-up.
Some of the interesting new features are:
- the ability to register and remove handlers at run-time;
- an attribute for executing events conditionally;
- another for repeatedly executing actions whilst a condition is true;
- the ability to create action handlers using script, which means that script can be interspersed with other action handlers.
XHTML Modularization
XHTML Modularization 1.1 (or M12N as is it is often called), is a set of guideines, DTDs and XML Schema modules that provide the basics of XHTML, ready to be recombined in different ways by language designers. An example of its use is XHTML Basic, aimed at mobile devices; this language is a sub-set of the full XHTML, and so uses only some of the modules provided in the M12N 'library'.
It's of particular interest to us at x-port, because we've been using compound document schemas for a few years now, and our work in this area has been fed into how these schemas are structured. We use a language created with M12N--we call it xH--that incorporates XForms, SVG, MathML and RDFa, both to drive the editing of our XForms documents, and to validate documents loaded into Sidewinder. The extension languages are defined as modules, following the principles of M12N, so they could be used in other languages, too.
Submitted by administrator on Tue, 02/13/2007 - 00:28.
|
