XForms and Internet Applications

Linked Data and RDFa in US and UK government web-sites

2009-11-20T12:28:00.002Z

And finally, I find this announcement exciting because the guidelines document uses the term 'Linked Data' throughout. This reflects an extremely deep understanding of the implications of what COI are doing with RDFa; the COI do not simply explain to people how to publish vacancies and consultations to the web -- they are describing how to publish that data to the Linked Data cloud.

Read more in Linked Data and RDFa in US and UK government web-sites, at my webBackplane blog.

Understanding the XForms dependency engine

2009-09-23T12:04:00.003Z

A key component of any XForms processor is the dependency-engine. The idea is pretty straightforward, and will be familiar to anyone who has used a spreadsheet; if some item has its value set by a calculated expression that contains references to other items, then when any of those items change, the first item must be recalculated.

Read more in my introductory article on the XForms Developer Zone site, Understanding the XForms dependency-engine.

RDFa Tech Talk, at Google, 2009

2009-09-21T11:41:00.002Z

Although my talk Beyond Web 2.0 -- How RDFa Can Help to Democratise Data on the Web, took place back in June, it's only just now been made available online, due to technical problems.

(I should say too, that those same technical problems also mean that the video is in 50's style black and white; maybe it gives it a bit more authority.)

I really enjoyed the session, and you'll hear at one point near the end I get to put some questions to Othar Hansson and Kavi Goel, and the rest of the Rich Snippets team, about how they'll be using RDFa going forwards.

Read more at RDFa Tech Talk, at Google, 2009 on my webBackplane blog.

XForms Developer Zone and User Group launched

2009-09-16T12:00:00.000Z

We're pleased to be launching two new initiatives to help people who are interested in XForms.

The first is the all new XForms Developer Zone web-site -- or xformsdz, as we're calling it.

Whilst the Developer Zone will be unashamedly biased towards XForms, within that, we'll have discussions, articles, code snippets, and tutorials about any XForms processor we can find, and any application framework in which it's used.

To accompany the web-site, we're also launching a regular newsletter, and a London XForms User Group.

Read more at XForms Developer Zone and User Group launched on my webBackplane blog.

Tokenising the semantic web

2009-04-30T13:21:00.004Z

To summarise the argument; first, we know that we need to be able to tokenise URIs, because they tend to be long and unwieldy. However, whilst the current use of prefixes to abbreviate URIs is useful, it only allows us to tokenise URIs that are used to identify vocabularies, and not full URIs. It's also not ideal that these prefixes are being expressed using a document architecture mechanism -- @xmlns.

By adding a new attribute -- @token -- to the CURIE processing rules, we can tokenise full URIs, which gives authors the same level of simplicity that Microformats has. The key difference though, is that this tokenisation is completely scaleable, and so overcomes one of the major drawbacks of Microformats.

Read more at Tokenising the semantic web on my webBackplane blog.

More RDFa goodness from UK government web-sites

2009-04-23T12:41:00.007Z

With my semweb consultantancy hat on, I've been working for a few months now on a number of RDFa projects with the UK's Central Office of Information. These projects have generally followed the same pattern:
define a vocabulary for some specific area of interest, such as job vacancies or government consultations;
use that vocabulary in HTML pages, via RDFa;
get my colleagues at webBackplane to build a prototype application using Drupal and ARC2, that both publishes and consumes pages in the right format;
add an application to Yahoo!'s SearchMonkey to process the RDFa pages.
A couple of days ago the UK Civil Service web-site was updated with a new look, and some exciting new features, some of which stem from the projects I've been involved in. There is still some more testing to do, so there haven't been any firm announcements yet, but I'm allowed to talk about one particular feature that is very exciting, the presence of RDFa in each of the job vacancies.

Read more at More RDFa goodness from UK government web-sites on my webBackplane blog.

RDFj: Semantic objects in JSON

2009-04-20T10:30:00.005Z

"Essentially, what we've done with RDFj is to map JSON to RDF -- with a few extra tweaks thrown in -- rather than simply mapping RDF to JSON. (RDFa took the same approach, starting with HTML, and then working out what RDF various patterns might represent.)

"There are of course many uses for the straightforward serialisation approach, taken by RDF/JSON. But we're finding that as our applications increasingly use both JavaScript and RDF, it's very useful to blur the lines between the two. RDFj takes us an important step towards that."

Read more at RDFj: Semantic objects in JSON on my webBackplane blog.

Update to 'Getting started with RDFa: Creating a basic FOAF profile'

2009-04-18T14:43:00.002Z

Just over a year ago I wrote a blog post that showed how to create a FOAF profile on a web page, using RDFa. The idea was not only to show how easy it was to do in terms of the markup, but also to illustrate that once you are able to publish RDF via a web page, you need nothing more than a blog page to join the semantic web.

This blog post updates that old post, by first adding some guidance on how to check your document (using the Ubiquity RDFa parser), and then proceeding to add more features to your blog page.

Read more at Getting started with RDFa: Creating a basic FOAF profile, on my webBackplane.com blog.

Customising initial instance data in an xform

2009-03-20T09:55:00.002Z

One of our customers recently asked:

"I have a question on how we can open an XForms page from a non-XForms page. We are trying to have a summary page which is a non-XForm page and we would like to try to open an already existing XForms page by populating data on to it dynamically, by clicking on a component in the summary page. More like a summary-to-detail functionality....

We are trying to find the best way to do this."

It's an interesting question, and although we have worked out a couple of ways of looking at this on the client side, I thought the best answer for now was to user the server.

Read more in Customising initial instance data in an xform, on my webBackplane blog.

Duck-typing and XForms

2009-02-03T12:41:00.003Z

In a recent code review on the Ubiquity XForms project, the question of whether to test for an element by name or properties came up. In this post we look at the benefits that can be had from using duck-typing as a way to manage objects' functionality, rather than the more usual hierarchical solutions.

Read more in Duck-typing and XForms, on my webBackplane blog.

Compact HTML: A mark-up language for micro-blogging

2008-11-07T14:40:00.002Z

This post also appears on Mark Birbeck's webBackplane blog.

When sending small comments via services such as Twitter, it's pretty straightforward to add links to other documents. The general pattern is to abbreviate the link using an online service, and then paste the shortened link into your post. Software that displays your posts can then replace any string that begins with http: with a real link.

However, there are many occasions where a link is just not good enough. Sometimes you'd like to embed an image, or even a video. But if we start trying to add HTML mark-up, we'll pretty soon hit the character limit imposed by micro-blogging platforms.

Enter compact HTML, or CHTML...for short.

Compact HTML

The simple idea of CHTML is that we use keywords to indicate the mark-up. For example, to add an image you would ordinarily write:

<img src="http://www.fineart.ac.uk/images/works/Dundee/90/du0008.jpg" />

Which would give you this:

Of course, we can shorten the fragment by using a URL service:

<img src="http://snurl.com/252rj" />

But we can go further if we make the mark-up compact:

img=http://snurl.com/252rj

That's a pretty efficient way to transmit an image in a post.

Why HTML?

You could ask how this relates to HTML?

The idea is that all elements and attributes from HTML can be used in a generic way. So the full version of the image we just saw, would actually be:

img(src=http://snurl.com/252rj)

We could also write:

img(src=http://snurl.com/252rj,alt=A picture of Stooky Bill)

Each element would have a 'default attribute' that anonymous values would set. In the case of img it would obviously be @src, so:

img=http://snurl.com/252rj

is equivalent to:

img(src=http://snurl.com/252rj)

Other tokens

Since all we're really doing is looking for patterns of the form:

token=value

then we needn't limit ourselves to HTML in our compact mark-up.

For example, we could express a YouTube video like this:

tube=http://snurl.com/25300

An example

To see this in action, take a look at the Compact HTML Twitter sample from the Ubiquity RDFa library. Note how two tweets from Stooky Bill are shown, one containing an image, and one containing a video. As you can see from Stooky's Twitter page, the actual tweets contain simple Compact HTML.

Microformats and RDFa are not as far apart as people think

2008-06-24T10:56:00.008Z

The BBC have caused a bit of a storm recently by announcing that they won't be using the hCalendar Microformat on their pages. The reason is the well-known problems with accessibility. One of the proposed solutions is to look at RDFa.

Read more in Microformats and RDFa are not as far apart as people think, at my webBackplane blog.

Openness and Innovation Presentation at Media Futures 2008

2008-06-21T14:22:00.003Z

Yesterday I had a lot of fun at the Media Futures 2008 conference at Alexandra Palace. The panel I was on was called Openness and Innovation, and included Robert Cailliau, Ian Forrester, Matt Webb and myself. The chair was Bill Thompson.

My slides are here:

| View | Upload your own

SlideShare Link

@role values for SVG

2008-05-17T19:12:00.003Z

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.

Upcoming talks on RDF, RDFa and XForms

2008-05-01T12:50:00.009Z

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.

So how about using RDFa in Microformats?

2008-03-21T15:03:00.005Z

Yes, I know...everyone seems to think that RDFa and Microformats are at war. And maybe some would prefer it to be that way. But whatever way you look at it, the work of the Microformats community has been key in getting people fired up about what they might do with metadata that is placed in HTML and XHTML pages. And RDFa is benefiting from the vibrant atmosphere which they have created.

That doesn't mean I'm saying we can ignore the problems and limitations that Microformats have, such as the difficulty in mixing different formats in one document, the work involved in creating new formats (often wastefully duplicating work that has already been done, since specialist formats invariably already exist), or perhaps most significantly, the inability to refer to things that are not 'the current document'.

So I have a suggestion.

Why don't we emphasise the 'micro' in Microformats?

Emphasise the 'micro'

One of the original motivations for Microformats was that they were small, self-contained sets of rules that authors could apply to their documents, which would give the author some kind of benefit. Nothing in that broad definition says 'so therefore steer clear of all other formats or you'll catch the plague'.

So why not use RDFa features within microformats, as appropriate? But Microformats could still retain the compactness of a particular format.

I'll use rel-license as an example.

rel-license

The rel-license microformat is simply the use of the value "license" in the @rel attribute, in some mark-up. For example, if we want to say that the current document is licensed under one of the Creative Commons licenses, we might use the following mark-up in our document:

<a rel="license" href="http://creativecommons.org/licenses/by/2.0/">cc by 2.0</a>

However, what if we have a search page that returns lots of images or videos? What if each image or video is available under a different license to other images or videos on the page, or to the license for the page itself? Trying to solve this problem within the framework set by Microformats is proving quite difficult (see the open issues on the rel-license issues page), so at some point we need something more than rel-license.

Reusing @src attribute

The mark-up we gave earlier to indicate that 'this document' is available under a certain license, amounts to two attributes, @rel and href:

<a rel="license" href="http://creativecommons.org/licenses/by/2.0/">cc by 2.0</a>

RDFa lets us take that little 'package' (or 'microformat') and use it anywhere that we can set a 'subject'. Of course normally the subject is the current document, which is why the rel-license microformat looks just the same to an RDFa parser as it does to a Microformats parser. But RDFa allows this 'package' to be used with the @src attribute, giving us the following possibilities:

<img src="my-picture.png" rel="license" href="http://creativecommons.org/licenses/by/2.0/" />

<object src="my-video.mov" rel="license" href="http://creativecommons.org/licenses/by/2.0/" /></object>

As you can see, this straightforwardly solves the problem that rel-license is presenting to those who want to put many items in a page, so all that would be required to take this solution into the Microformats world would be to slightly extend the rel-license microformat to allow the src attribute as a subject.

RDFa or Microformats?

This example illustrates that if we see RDFa and Microformats as playing slightly different roles, then there is no need to take an 'either/or' approach to the two techniques.

Since RDFa is a general-purpose syntax that is capable of supporting any vocabulary that anyone comes up with, now or in the future, then we are often tempted to talk about the general rules. But for new users who are looking to achieve a specific goal, seeing documentation about a specific usage pattern (such as the one I've shown here with licensing), will almost certainly be more useful to begin with.

But that is what Microformats is all about--documenting common usage patterns in such a way that people can re-use them in their own mark-up. So what would be wrong with enhancing rel-license to allow the use of @src?

Note that people wanting to parse this microformat could either create a specific parser in the way that they need to do now for other microformats, or they could use a general-purpose RDFa parser.

The key thing is that the mark-up is exactly the same, whether you arrived at the use of @rel="license" via the Microformats page, or an RDFa page.

And that seems to me to be a good result all round, for the authors, for the programmers, for the search engines, and especially for those of us who want to see a more dynamic, usable, and semantic, web.

First steps in RDFa: Creating a FOAF profile

2008-03-03T13:47:00.007Z

Please note that this article has been updated to Getting started with RDFa: Creating a basic FOAF profile.

Now that the RDFa syntax document is in last call, and people like Yahoo! are starting to index the data, it's worth putting more of your own data into your web-pages, using RDFa. A simple place to start is to modify your home-page or blog profile so that it includes FOAF information.

FOAF

If you're not familiar with FOAF, or Friend-of-a-friend, it's a set of terms that can be used to describe people, organisations, and their relationships to each other. For example, we can mark up our names, point to our home-pages, indicate the companies and projects we work on (and point to their home-pages), and so on.

Since this vocabulary is gaining in popularity, and since RDFa allows us to use any vocabulary we like without having to re-write it (or ask anyone), we'll use FOAF via RDFa to mark up our pages. We won't use every part the vocabulary, so if you want to find further properties, or more detail on the properties used below, look at the full FOAF specification.

Creating a person

The first thing we need to do is to create a person object that will hold our information. This is done using the RDFa typeof attribute, which is much like @class in HTML. The type of the object we want to add is a Person and since 'person' comes from the FOAF vocabulary, we write it like this:

<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <head>
    <title>Mark Birbeck's profile</title>
  </head>
  <body>
    <div typeof="foaf:Person">
      ...
    </div>
  </body>
</html>

Now we're ready to add our personal information to this block.

Adding personal information

The FOAF vocabulary is packed with useful properties that we can set, so let's start with some basics such as our name and the URL for our blog.

We can add our name using the foaf:name property, which is set via the new RDFa property attribute:

    <div typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
    </div>

Our blog is indicated using the foaf:weblog property. However, unlike foaf:name which is simply a string of text, the item we're going to refer to is a URL, so we must use the HTML rel attribute instead of @property:

    <div typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
    </div>

Creating a profile

We now have a person with some properties about them, but in FOAF terms that's slightly different to having a profile about the person. If that seems a little subtle, it is, but what it amounts to is that the document that contains information about me, is not actually me. In many situations it won't appear to make any difference, but unfortunately it can cause a lot of problems. For example, if the document is used to represent both my profile and me at the same time, what would be the result of adding some information about when the document was created? How do we know whether the information is indicating when I was born, or when the document was?

FOAF allows us to prise these two things apart with the foaf:primaryTopic property, so we're going to use this to say that the main subject-matter of our profile (a web document) is me (a person):

<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <head>
    <title>Mark Birbeck's profile</title>
    <link rel="foaf:primaryTopic" href="#me" />
  </head>
  <body>
    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
    </div>
  </body>
</html>

Whilst we're here, it might be useful to use the foaf:maker property to indicate who created the profile; in this case it's the same as the subject of the profile (i.e., the person who the profile is about), so it's easily set as follows:

<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <head>
    <title>Mark Birbeck's profile</title>
    <link rel="foaf:primaryTopic foaf:maker" href="#me" />    
  </head>
  <body>
    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
    </div>
  </body>
</html>

Now we can read this whole thing as follows:

we have a person that is identified as #me;
this person has a name of "Mark Birbeck";
this person has a blog at <http://internet-apps.blogspot.com/>;
this person is the creator of the current document;
this person is the main subject of the current document.

Adding friends and colleagues

Now that we have our basic framework in place, it's pretty easy to drop more and more FOAF properties in. Perhaps the most commonly used is foaf:knows which is used to indicate the people that you know. Since the target of this property is once again a URL, we'll need to use the HTML rel attribute again:

    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
      <a rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me">Ivan Herman</a>
    </div>

Adding a picture

The FOAF vocabulary also allows us to indicate pictures that we appear in, and pictures that we might want others to use to represent us. To set a picture of yourself that other software might use to represent you, use the foaf:img property:

    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
      <a rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me">Ivan Herman</a>
      <span rel="foaf:img">
        <img src="http://www.formsplayer.com/files/pictures/picture-11.jpg" alt="Picture of Mark Birbeck" />
      </span>
    </div>

Linking to a Twitter account

The final illustration we'll show is how to use the FOAF vocabulary to point to your Twitter account, which will make it easy to build tools that will allow people to follow you with one click. The first thing to do is create a relationship called foaf:holdsAccount, which will connect our 'person object' with an online account object. To connect two objects we use the HTML rel attribute again:

    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
      <a rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me">Ivan Herman</a>
      <span rel="foaf:img">
        <img src="http://www.formsplayer.com/files/pictures/picture-11.jpg" alt="Picture of Mark Birbeck" />
      </span>
      <span rel="foaf:holdsAccount">
        ...
      </span>
    </div>

Next we create an object of type foaf:OnlineAccount, in exactly the same way that we did when creating a person earlier:

      <span rel="foaf:holdsAccount">
        <span typeof="foaf:OnlineAccount">
          ...
        </span>
      </span>

Finally, we indicate that the particular type of account we're dealing with is a Twitter account (using foaf:accountServiceHomepage), and also provide our account name (using foaf:accountName):

      <span rel="foaf:holdsAccount">
        <span typeof="foaf:OnlineAccount">
          <a rel="foaf:accountServiceHomepage" href="http://twitter.com/">Twitter</a>
          <span property="foaf:accountName">markbirbeck</span>
        </span>
      </span>

Human and machine-readable

Everything we've marked up so far is human and machine readable, but the layout is not great for a human. Although the links to the blog will work, and the text will show names and accounts correctly, there is no context information. However, additional mark-up can be placed in the document, and as long as it is outside of the scope of the RDFa attributes it won't be classed as metadata. For example:

<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <head>
    <title>Mark Birbeck's profile</title>
    <link rel="foaf:primaryTopic foaf:maker" href="#me" />    
  </head>
  <body>
    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span> writes a blog called
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>.
      He knows
      <a rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me">Ivan Herman</a>.
      <span rel="foaf:img">
        <img src="http://www.formsplayer.com/files/pictures/picture-11.jpg" alt="Picture of Mark Birbeck" />
      </span>

      His inane comments are available on his
      <span rel="foaf:holdsAccount">
        <span typeof="foaf:OnlineAccount">
          <a rel="foaf:accountServiceHomepage" href="http://twitter.com/">Twitter</a>
          account. His ID is '
          <span property="foaf:accountName">markbirbeck</span>'.
        </span>
      </span>

    </div>
  </body>
</html>

The whole shebang

If you want to use the mark-up as a template, then here is everything that we've seen, above. Just replace the values in red with your own details, add any human-readable text you want around it, and you are off and running:

<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <head>
    <title>Mark Birbeck's profile</title>
    <link rel="foaf:primaryTopic foaf:maker" href="#me" />    
  </head>
  <body>
    <div about="#me" typeof="foaf:Person">
      <span property="foaf:name">Mark Birbeck</span>
      <a rel="foaf:weblog" href="http://internet-apps.blogspot.com/">XForms and Internet Applications</a>
      <a rel="foaf:knows" href="http://www.w3.org/People/Ivan/#me">Ivan Herman</a>
      <span rel="foaf:img">
        <img src="http://www.formsplayer.com/files/pictures/picture-11.jpg" alt="Picture of Mark Birbeck" />
      </span>

      <span rel="foaf:holdsAccount">
        <span typeof="foaf:OnlineAccount">
          <a rel="foaf:accountServiceHomepage" href="http://twitter.com/">Twitter</a>
          <span property="foaf:accountName">markbirbeck</span>
        </span>
      </span>

    </div>
  </body>
</html>

Publishing your FOAF page

Since our FOAF page is embedded into an HTML page, then you can publish your FOAF profile pretty much anywhere that you are able to publish HTML or XHTML. Unfortunately, I was not able to update my Blogger profile to include RDFa, so instead I've created a new blog page, which contains my profile. You'll see a few minor changes to the structure described above, to take into account that we're not creating the entire page, but essentially it's the same.

My Profile

2008-03-03T13:46:00.000Z

The following is a sample profile, created using the techniques described in the post First steps in RDFa: Creating a FOAF profile:

Mark Birbeck has spent the last 7 years designing, building and thinking about a framework that enables dynamic user interfaces, driven by data content. Such a framework can dramatically increase programming productivity, and open up the world of application-building to many more people. Since he believes that the framework should be built on open standards, Mark is heavily involved in the W3C, as an invited expert with the XForms and XHTML 2 Working Groups, and also as the designer of RDFa.

His companies created the formsPlayer XForms processor, and Sidewinder, an open source, next-generation semantic web browser.

His blog focuses on building a new generation of internet applications, and a number of entries relate to Ajax, XForms, the semantic web, and the use of declarative mark-up. You can find him on Twitter, where his ID is markbirbeck.

RDFa is now in last call

2008-02-21T22:28:00.003Z

After a great deal of effort by some very dedicated people, the RDFa in XHTML: Syntax and Processing document has entered last call. The full story is on the front-page of the W3C site, or at this permalink. The status of 'last call' means that as far as the people who have been involved in creating the spec are concerned, any technical problems that might have existed have been resolved. Now it's the turn of the wider community to make comments about the document, and even try to implement RDFa processors.

If you want to read more about RDFa, I've blogged a lot about RDFa, written an Introduction to RDFa, and presented on it. Bob DuCharme's Introducing RDFa is, as we'd expect from him, a great introduction, and Manu Sporny uses his vocal and artistic talents to provide RDFa Basics in video form.

Google's Social Graph API, RDFa and the future of web search

2008-02-13T10:30:00.007Z

One of the main goals of RDFa (syntax and primer), and its precursors, is to provide richer semantic information for search engines. In one of my early drafts I gave the example of a news story that referred to the British Prime Minister:

Yesterday in Parliament the Prime Minister said that we will fight them on the beaches.

Such an article would be easily understood on the day of its publication, and even years later, someone reading this would probably know who the Prime Minister in question was, and possibly even be able to decipher 'yesterday'.

But what about trying to find this article? If I search in Google for articles about Prime Ministers I'll retrieve articles about the Australian and Malaysian PMs, both of whom are in the news this week, as well as links to the 10 Downing Street web-site, stories about Gordon Brown, and so on. And if I search for "Winston Churchill" the article we're using as an example won't appear, since his name does not occur in the text.

So the original proposals for RDF in XHTML--now called RDFa--suggested that one way to solve this problem would be to allow metadata about anything to be added to HTML and XHTML documents. The example given above was extended as follows:

Yesterday in Parliament the <span resource="p:WinstonChurchill">Prime Minister</span> said that we will fight them on the beaches.

The identifier p:WinstonChurchill was a made up placeholder, indicating simply that we need a unique identifier that tells us that this particular person is Winston Churchill, but since writing that early draft, DBPedia has come along, which means that assigning a unique identifier for the person Winston Churchill is easy.

So if we have the identifier, and we have a way of adding the mark-up, all we need now is to get the data into the search engines, so that we can use them to find the article.

And Google's Social Graph API shows that this is already possible.

Google have released an API that allows us to search for people and their relationships to each other. The data is gathered during the normal indexing process, as long as it is provided to the indexer using the XFN microformat or via an external link to a FOAF document. This shows some interesting developments; first, that the Google indexing process is flexible enough to pick up different sorts of information and tie it back to a URL, and second that the search process is flexible enough to allow users to search for these different types of information in different contexts.

So the logical next step is to add an RDFa processor to the Google indexing pipeline. Since RDFa is a generic language, able to express not just FOAF, but any RDF vocabulary, then Google will only ever need to add one RDFa processor to their system, and that processor will allow them to index all current and future RDFa, even if documents use vocabularies that hadn't even been invented at the time the processor was installed.

This is a very different approach to the Microformats technique, since with Microformats, each format is unique and has its own parsing rules, which would mean that Google would have to add a different processor for each format. Not only that, it's very difficult to make multiple Microformats in the same document play together, and since each Microformat has to be centrally approved, there is no great momentum being built towards formats for disciplines such as engineering or chemistry.

None of which is to belittle the fact that getting XFN indexed by Google is a great start. But whilst I've given examples here that use people, since that is what the Social Graph API does, my point is that everything is in place for something far broader; imagine that chemists could search for any document about a particular compound or molecule (see RDFa, chemistry and the sharing of knowledge), or that doctors were able to find all references to a certain disease. In any number of different specialisms, experts have already created the vocabularies that are relevant to their communities, and RDFa has finally made it possible for these vocabularies to be used directly in news stories, peer-reviewed papers, blogs posts and more, via HTML and XHTML. (RDFa is in the final stages of becoming a W3C-approved specification, but is already in use in many different environments.)

To complete the triangle, we now need the search engines to start indexing this data, and Google's Social Graph API initiative shows that this is finally a technical possibility.

Creating desktop applications with Popfly and the Sidewinder Viewer

2008-01-22T22:57:00.001Z

I've seen a lot of impressive Silverlight and Popfly applications, but one of the limitations I see is that they always have to be run through the web browser. So I've posted a set of video tutorials to YouTube that show how to use a Popfly mashup as a desktop application, using the Sidewinder Web Applications Viewer. The complete collection is available as a tutorial on the Sidewinder Viewer site.

The first tutorial creates a Popfly mashup that shows Facebook friends in a rotating carousel, to be used in the later tutorials. (So if you are comfortable with Popfly, or you already have a mashup that you would like to use as a desktop gadget, you can safely skip to the second tutorial.)

The second tutorial makes use of the mashup created in the first tutorial, to show different ways that it can be run as a gadget on the desktop, simply by altering the URL that is used by the Sidewinder Viewer to load the mashup. No manifest files are needed to control an application on the destop -- we can control size, position, chrome, opacity, transparency, docking and autohide behaviour through the URL that is passed to the Sidewinder Viewer -- so all you need is the URL of a Popfly mashup to get started.

The final tutorial first shows how to make the carousel float on top of all other applications on the desktop, with no chrome or background. It then goes on to describe how to write an event handler in JavaScript that will control how new windows are created; clicking on a friend in the image carousel causes a new window to open showing the friend's Facebook profile, and thanks to the event handler, this new window will be docked to the side of the screen, and set to automatically hide when it loses focus.

It's also possible to pass events between the windows that are created, which creates all sorts of possibilities for one Popfly gadget to communicate with another. I'm planning to create further tutorials to illustrate what can be done thing, but I'm also interested to hear what applications people are thinking of building, so I look forward to any comments.

Welcome to Planet XForms

2008-01-20T11:05:00.000Z

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.)

Yahoo! uses XForms for 'write once, run anywhere' mobile applications

2008-01-08T15:44:00.000Z

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:

skimming at XML 2007 (and The Cloud's Silver Lining)

2007-12-14T16:51:00.000Z

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.

RDFa, @profile, and following your nose

2007-12-10T11:16:00.000Z

a monument to Gogol's "Nose"
Originally uploaded by Incandenzafied

One of the issues that people continually return to in relation to metadata in HTML (and with RDFa in particular), is how to know when it is safe to interpret some mark-up as 'additional' metadata. This often gets termed 'following your nose', since the idea is that you should be able to obtain from the document you are processing the information you need to add an extra layer of interpretation to the mark-up.

(This shouldn't be confused with the other form of 'following your nose', practised by Gogol's Major Kovalyov, which is an altogether more fraught experience.)

For example, if we were processing an HTML document that contained the hCard microformat, we might have:


<span class="fn">Mark Birbeck</span>

The nose-related question being posed is, how do we know that it is legitimate to interpret the value called out by "fn" as a full-name? Is it not possible that on some occasions an author has simply created a @class value of "fn" to help their CSS?

@profile

One way this question is answered in the world of microformats is to use the profile attribute to 'scope' these values; if the author has added the following, to the top of their document:


<head profile="http://www.w3.org/2006/03/hcard">

then it is pretty clear that they want "fn" values to be interpreted as a 'full name', and it would be quite legitimate for a parser to extract this value and do something with it. The complete mark-up might look like this:


<html>
 <head profile="http://www.w3.org/2006/03/hcard">
  .
  .
  .
 </head>
 <body>
   <span class="fn">Mark Birbeck</span>
 </body>
</html>

This is a good solution for microformats, since there are quite a few of them. Each microformat has different rules for parsing, so indicating the presence of one or more microformats in the profile attribute works well, and is very much in the spirit of the original meaning of @profile in HTML.

But what of a generic solution like RDFa? Does the same situation arise?

RDFa is unambiguous

RDFa uses new attributes, as well as full identifiers for properties and values, so the problem of ambiguity does not arise. To make use of the FOAF value name an author would declare a namespace prefix, and then use any values that are enabled by that prefix, as follows:


<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
 .
 .
 .
 <body>
   <span property="foaf:name">Mark Birbeck</span>
 </body>
</html>

This is about as good as it gets, since it makes use of existing, well understood XML techniques to define properties unambiguously. And since it is using the new property attribute, it is nigh on impossible that we would happen upon this mark-up in a situation where the author intended some non-RDFa meaning. In other words, RDFa provides a far better solution than the usual 'follow your nose' approach, which would have us load some kind of profile (as practised by microformats and GRDDL), since it requires no other indications in the document to help discern meaning, other than a few simple, generic, rules.

Indicating the presence of metadata

However, there is a separate problem that is often raised in conjunction with RDFa, which is how to know whether to actually parse the document or not; if an author has not included any RDFa, why spend time processing it?

This is not a problem unique to RDFa, being constantly raised in relation to all sorts of document types, since there are of course many situations where it would be preferable to know something about the content of a document before opening it and processing it.

But that should flag up to us that just because it would be desirable in some situations to avoid the extra processing, it does not mean that a flag to indicate the presence of RDFa should be hard-coded into the syntax and made mandatory, as many are suggesting. In fact, some argue that without such an indicator, the whole structure of RDFa will collapse, which is simply not the case. Since RDFa is unambiguous, detecting its presence is merely about saving on processing time, and is therefore best seen as a use-case...and as a use-case it is no more or less important than other use-cases, such as those that might involve the processing of every single HTML document.

The confusion that has arisen around the use of @profile in RDFa is caused by the merging the two--distinct--issues, that of ambiguity of meaning, and that of 'detecting' the presence of RDFa.

Confusion

When using microformats, the question of ambiguity and the 'presence' of microformats are one and the same. This is necessarily the case because microformats make use of existing HTML attributes, such as class and abbr, but populates them with values that are indistinguishable from the ordinary use of such attributes. It is therefore imperative that a microformat parser (or indeed a GRDDL processor) does not process the values unless it is given some indicator that it is safe to do so.

RDFa on the other hand uses new attributes, so the presence or otherwise of RDFa is clear. And in the cases where existing HTML attributes are used (namely @rel and @rev), RDFa values are 'scoped' anyway, so the ambiguity question does not arise.

This means that if an RDFa processor were to process every document it found, it would be extremely unlikely to come to any 'conclusions' that were invalid. That doesn't mean that every processor should parse every document, but it does show that the question of 'presence' relates to optimisation rather than being a fundamental issue.

Conclusion

RDFa does not have the same problem as microformats in relation to ambiguity. So whilst the use of @profile in microformats is a good way to resolve the ambiguity problem in that context, it is simply irrelevant for RDFa. That doesn't mean we might not wish to indicate when it is worth parsing a document for RDFa, and one way to do this may be to use @profile. But we have to be clear that ambiguity of terms and detecting the presence of content, are two separate problems.

Embedding OWL-RDFS syntax in XHTML with RDFa

2007-12-02T15:40:00.000Z

David Decraene is looking for feedback on his article Embedding OWL-RDFS syntax in XHTML with RDFa, which is a "Short introduction to RDFa, OWL and Microformats", and aims to come up with:

a solution that reconciles the ease of use of Microformats with the expressivity of a language like OWL. Some problems hindering OWL adoptation will be highlighted, and a first experiment with the use of RDFa mark-up to embed OWL data directly into an XHTML page will be demonstrated, a solution that can be considered as a step higher than Microformats on the evolutionary ladder of the web.

He argues that OWL has a poor presence on the web, attributing this mainly to the fact that no-one has explored approaches to "align / integrate OWL with current web content":

For ontological data to truly be useful, you need to somehow tie current web content with semantic classes and instances. OWL has failed miserably in this respect so far. It is much like a far away island of Eden, and a man without a canoe. All the important data could be there but no-one knows how to reach it. Granted, OWL does define a standard format for data interchange between applications, but this limited scope cannot be what the semantic vision is about.

Interestingly enough, if you replaced the word 'OWL' with the word 'RDF', you'd have pretty much the main motivations that spurred the development of RDFa in the first place. David goes on to give an example:

What we need is semantic annotation. You need to be able to tag sections of your content with explicit ontology classes and even relations, without it hindering the display of your content. If you wrote a piece on a certain bordeaux for example, you could mark up the section as being about an instance of wine, perhaps even with some properties defined (or even more amazing, just by knowing it is about wine properties can be extracted automatically, a mention of red is bound to be about the wine color).

Whilst there is no doubt that the kind of complex RDFa David uses in his post is not for the everyday user of RDFa, the fact that RDFa can be used for these kinds of complex examples shows that the architecture is solid.

Once more on information resources and RDFa

2007-11-21T21:41:00.000Z

Benjamin Nowack has a great explanation of how RDFa deals with the very tricky issue of information resources, and indeed, offers a unique solution to the problem. (His post is in response to Ian Davis's post, Is the Semantic Web Destined to be a Shadow?.) I agree with all of Benjamin's post, and in particular it's very impressive that he draws attention to some very subtle issues, such as why it was important not to include @id processing in RDFa.

However, there is one point where I think I would be more positive than Benjamin--or perhaps a better word would be 'optimistic'. Either way, he says towards the end of his post:

One practical issue remains, though: Current browsers don't (natively) support navigating to RDF identifiers encoded in RDFa-, microformats-, or GRDDL-enabled HTML pages.

That is true, but given the points that Benjamin has made earlier in the post about how we should be careful when using URIs with fragment identifiers, this navigation question might be a non-issue. After all, if we want to navigate to some point in another document, then by definition we are dealing with an information resource anyway, and so it's legitimate to use an @id.

RDFa cleanly copes with the difference between resources that you might want to navigate to, and those that you might only want to refer to, by supporting the use of two different attributes--@href and @resource. In terms of the triples generated there is no distinction between the two, but there is a big difference in terms of their behaviour--only @href yields a clickable link, in the normal HTML manner.

Illustration

To illustrate, let's say that in my profile I indicate an identifier for me, as well as my name:

<div about="#mark" instanceof="foaf:Person">
  <span property="foaf:name">Mark Birbeck</span>
</div>

This means that anyone can now refer to my 'identifier', perhaps to indicate that they know me. But it would be wrong to create a clickable link to that identifier, since as Benjamin is correctly implying--and this lies at the heart of the debate about information resources and ordinary resources--I am a person and not a web-page. (If you are interested in this topic, I wrote a longer post about some of these issues back in May last year, called The Information Resource Debate, and RDFa.)

However, whilst it would not be a good idea to create a clickable link that points at my identifier (or 'me', to all intents and purposes), there would be nothing wrong with creating a clickable link that refers to my home-page.

So, to illustrate all of this, let's say that Benjamin used the following mark-up in his web-page, to both indicate that he knows me, and to link to my home-page:

<div about="#benjamin" instanceof="foaf:Person">
  <span property="foaf:name">Benjamin Nowack</span>
  knows 
  <div rel="foaf:knows" resource="http://some.profiles.com/mb#mark">
    <span property="foaf:name">Mark Birbeck</span>
    (<a rel="foaf:homepage" href="http://internet-apps.blogspot.com">home page</a>)
  </div>
</div>

As you can see, the distinction has been made between a link to a resource that is another web-page (known as an information resource) and a link to a resource that is a person--one uses @href and the other uses @resource.

Intelligent links

In the future I see this being optimised in a very interesting way, as follows.

I already have a client-side RDFa parser that whilst parsing will load many of the external documents it comes across, in the hope of finding even more triples. Once parsing is complete, the document being viewed in the browser is 'augmented' with some of the additional information that was found in the triples.

With this behaviour, it means that in mark-up someone only needs to indicate that they 'know' me, and the RDFa parser does the rest, providing other information gathered from my profile. For example, continuing with the above example, Benjamin could change his mark-up to this:

<div about="#benjamin" instanceof="foaf:Person">
  <span property="foaf:name">Benjamin Nowack</span>
  knows 
  <div rel="foaf:knows" resource="http://some.profiles.com/mb#mark">
    <span property="foaf:name">Mark Birbeck</span>
  </div>
</div>

The parser would see the reference to my profile and load it, looking for more triples, and one of the triples that would be gained would be the URL for my home-page:

<div about="#mark" instanceof="foaf:Person">
  <span property="foaf:name">Mark Birbeck</span>
  <a rel="foaf:homepage" href="http://internet-apps.blogspot.com">home page</a>
</div>

The final step is for the parser to add a navigable link to the div or span associated with me in the document being parsed, using of course the URL of my home-page. And what's really neat is that if I were to change my home-page and re-publish my profile, anyone using the reference to my profile wouldn't need to do a thing to get the updated link to my home-page.

Conclusion

In my view this kind of functionality shows the benefit of keeping the world of resources and information resources apart; in the latter examples you can see that what the author is marking up is in many ways more 'correct', since they are expressing a relationship between people (i.e., that they know each other) rather than the merely technical notion of 'here is someone's web-page'.

Using URLs to pass parameters to web applications, widgets and gadgets

2007-11-20T21:28:00.000Z

The Sidewinder Viewer contains a growing number of innovative features, and one I'd like to highlight here is the ability to pass run-time parameters for a web application, via a URL.

`meta` and `link` values

You'll probably already know that Sidewinder can make use of values in the HTML meta element to set things like its initial position, the size and width of the initial window, opacity and transparency, and so on. The ability to place important information like this into the document itself is a simple but powerful technique, since it means that you don't need to create manifests containing configuration information, giving you one less file to maintain and deploy.

However, whilst this technique is simple and straightforward when you are building your own application, what happens when you want to run someone else's web application on your desktop? Or what should you do if you want to take the map display you've created and re-use it as a large desktop application one minute and a small gadget the next? Surely we don't have to create two documents that are exactly the same except for the height and width?

The answer to both of these question is to move some (or all) of the run-time parameters that are in the head of the document, out to the end of the URL. To do this we use the meta and link XPointer schemes.

Google Reader

For example, let's say that you wanted to load Google Reader into a window that was 900 by 500, positioned at the top of the display, and that would autohide when you moved the mouse away; this is easily achieved by slightly modifying the URL used to open Google Reader in Sidewinder, as follows:

swviewer2 http://www.google.com/reader#meta(width=900,height=500,autohide,position=top)

The result would be something like this:

Similarly, what if you wanted to run the Facebook iPhone application as a gadget on your desktop, with no chrome, docked to the side, and using the same dimensions as an iPhone? As before, take the base URL of the iPhone application, and then add the relevant meta parameters before passing the whole thing to Sidewinder:

swviewer2 http://iphone.facebook.com#meta(width=320,height=480,chrome=false,autohide,position=right-top)

The result would be something like this:

Command-line parameters

Putting parameters into the URL like this essentially places the command-line parameters that one would ordinarily expect to use when running an application--such as blah.exe -height=500 -width=900--into the URL. This in turn has the important effect of 'factoring out' the application that acts on the URL, by which I mean that the application is now transparent to the whole process of running our web application.

That might seem a little obtuse, but the point I'm making is that by using XPointer frameworks like this, we have leveraged perhaps the most important invention of the web, the URI. And just as URIs are often used as a universal document identifier, independent of any browser used to view that document, so we use URIs as a 'universal command-line', independent of any web applications processor that might process that command-line.

User control

But this only tells half the story. For me there is something even more exciting, which is that this technique puts control over the use of an application into the hands of the people running it. For example, we just saw how the size and position of the Google Reader web application can be set in the URL with the meta XPointer framework, but we could go further than that and use the link XPointer framework so that when we run the application we use a different stylesheet. We could even refer to a script, some RDFa, and so on.

Next steps

The next step with this work is to start to formalise the concept, so that it can be used in many different circumstances. For example, although we've seen here how the technique can be used when running web applications with the Sidewinder Viewer, it would also be possible to use run-time parameters when loading widgets into frameworks such as iGoogle, passing in parameters such as preferred colour-scheme, nearest city, and so on. By having some kind of specification it will also make it possible for others to comment and provide input on how to take this work forward.

Sidewinder is open source and gets a new home

2007-11-15T20:59:00.000Z

The transition of Sidewinder, our semantic web applications viewer, to an open source project is now complete. It took quite a lot of work in a number of different areas, but we're convinced that this will now help us realise the full potential of the framework.

The first thing that had to be done was of course to ready the code. Phil Booth, the lead developer on the viewer, put a lot of work into general tidying up, reordering components for Subversion, and so on. He also did some important work that takes us in a cross-platform direction, such as removing our dependency on MFC, and putting the platform on top of wxWidgets.

Alongside this work, we also had to spend time looking at the best way to host the code, how to support bug-tracking, where to put discussion forums, and so on. We looked initially at the environments like SourceForge and Google Code that do everything for you, but in the end we liked the look of Trac so much that we felt that was the way to go. And since there seemed to be a number of advantages to hosting our own SVN repositories, we ended up with the following arrangement:

an Amazon EC2 instance running:
- Drupal for the main Sidewinder Viewer site;
- Trac for the Sidewinder Viewer developer site;
- and SVN for the Sidewinder Viewer source repository;
a SourceForge project to host the downloads;
two Google Groups for discussions--one for developers that use Sidewinder, and one for developers who are working on Sidewinder.

So far this arrangement is working pretty well, and in particular Trac and SVN are a fantastic match.

Getting started with Sidewinder

The fastest way to get started with Sidewinder is to look at the post The 10 minute guide to Sidewinder (or 'How to turn a web app into a desktop app without programming') on the swcube site. Not only does it show how to run a web application like Google Reader in its own window, docked to the side of the screen, and set to auto-hide, but it also shows how to turn an iPhone application into a desktop gadget.

Sidewinder can also run embedded in the browser, execute JavaScript applications from the command line, and more, but its ability to run web applications as standalone applications is such a useful feature that it's an excellent place to start.

Converting HTML to RDF

2007-10-25T08:56:00.000Z

An interesting discussion came up recently on the 'RDF in XHTML' taskforce mailing-list. The question was asked:

I was wondering whether anyone has tried to transform HTML into RDF.

The obvious answer was to describe how the content of the HTML document could be extracted, using RDFa, for example, or XSLT as used by GRDDL and the guys at SIMILE. But it seemed to me that the question had a slightly deeper meaning.

To convert HTML to RDF would not simply be to take out the content, but to actually convert the document's structure to RDF. For example, at the moment if an RDFa parser sees this mark-up:


 <img src="http://...holiday.png" />

it will not generate anything. If it sees this:


 <img rel="foaf:depiction" src="http://...holiday.png" />

then it will generate a triple that establishes are relationship between some object and a resource, stating that the resource is a 'depiction' of the object:


 <> foaf:depiction <http://...holiday.png> .

However, you could not round-trip the document from this information. I.e., you could not take the triples and reconstruct the HTML document, or construct some other document in a different language (say Docbook) based on the higher level metadata you've stored. For that you would need to store triples that relate to the elements in the mark-up. In other words, even the first example, with no @rel value, would need to generate some triples, even if it's as simple as:


 <> xh:img <http://...holiday.png> .

Obviously this is a discussion for the future, but I believe this to be an important scenario for the 'next generation web'. This is because, by storing the 'intent' of your mark-up rather than the mark-up itself then you would be insulated from changes to rendering language, it would be much easier to be device-independent, you could deliver different versions of a document to different audiences, and so on.

One step closer to bridging the clickable and semantic webs

2007-09-22T10:34:00.000Z

We've reached a point where new editors' drafts of the syntax and processing document, and an introductory primer are available, ready to be reviewed by the W3C's Semantic Web Deployment Group at their next face-to-face meeting.

Take a look. RDFa is pretty close to completion...and now the fun can really begin.

Sidewinder and the need for a semantic web applications framework

2007-08-28T19:23:00.000Z

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.

Fixing the web, Part 1

2007-08-22T08:42:00.000Z

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'.

Ajax and progressive browser enhancement

2007-07-17T10:35:00.000Z

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.

RDFa used in Joost

2007-07-13T10:32:00.000Z

Joost have started to put a little RDFa into their pages. To see an example, here's a link to a documentary about Ancient Rome. Each of the entries in Joost has a page like this, containing information about the video. If you do a 'view source' you'll see that the first thing the document does is declare the namespaces that will be needed:

<html
 xmlns="http://www.w3.org/1999/xhtml"
 lang="en" xml:lang="en"
 xmlns:foaf="http://xmlns.com/foaf/0.1/"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
>

This simply indicates which vocabularies are going to be used in the docment--in this case FOAF and Dublin Core.

The first piece of mark-up that's of interest is that the concept primaryTopic from the FOAF vocabulary is used to indicate what exactly this page is about. This simply involves using a link element to point to the relevant part of the HTML document, and using a prefixed value for the property (in @rel):

 <head>
  <title>Joost™ Link: Treasure Seekers: In The Shadow of Ancient Rome</title>
  ...
  <link rel="foaf:primaryTopic" href="#video-itself" />
  ...
 </head>

This has established that the primary topic of this document is some other part of the document, and if you understand triples you'll know that this means:

<http://www.joost.com/032001z> foaf:primaryTopic <http://www.joost.com/032001z#video-itself> .

Next the document has some text that the user can read. But the advantage of using RDFa is that both data and metadata can be combined into a single document; in this case the text that the user can read can also become metadata about the video, making use of the concepts 'title' and 'description' from Dublin Core:

 <body>
  ...
  <div id="contentArea">
   <!-- content area -->
   <div about="#video-itself">
    <p property="dc:title">Treasure Seekers: In The Shadow of Ancient Rome</p>
    <p property="dc:description">
     Wealthier and more powerful than any other ancient civilization, the
     Roman Empire enjoyed a long period of prosperity. But perhaps the
     greatest treasure of this period was not its riches, but its myth.
     Join National Geographic and relive the glories of the Roman Empire
     and see why it has inspired dreamers and dictators throughout the ages.
    </p>
   </div>

This would give us the following triples:

<http://www.joost.com/032001z#video-itself> dc:title "Treasure Seekers: ..." .
<http://www.joost.com/032001z#video-itself> dc:description "Wealthier and more powerful ..." .

Later in the document there is a section of 'additional information' about the video, and the mark-up here shows another feature of RDFa; the ability to have metadata that is more precise than the text used for human readers:

  <div id="additionalinfo" about="#video-itself">
    ...
    <p property="dc:subject" content="Documentary">Category: Documentary

    ...
   </div>
  </div>
  ...
 </body>
</html>

This gives another triple that explains the subject-matter of the documentary:

<http://www.joost.com/032001z#video-itself> dc:subject "Documentary" .

The advantage of this feature is that even if the inline text were in a different language for different audiences, the metadata produced would still be the same.

The way Joost are beginning to use RDFa shows that with just a handful of attributes, information about the content of the document--and its purpose--has been made available, to external processors. This could then be used to obtain further information about the film, or even find other films on similar topics. This is one of the primary use-cases for RDFa, so it's exciting to see the data being made available in this way; who is going to be the first to create some functionality in Operator to make use of it?

Of pots and kettles (more squabbling between Sun and Microsoft about standards)

2007-07-10T09:14:00.000Z

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.

Yowl: Design principles and how to use it

2007-06-29T14:58:00.000Z

Yowl is an open source project inspired by the Growl centralised notification system for Mac OS. Growl provides a set of functions that applications can call whenever they want to display a notification to the user, and since the user is able to configure how each message is displayed--including suppressing it altogether--the user gains control over the notifications that they'll receive from an application.

Yowl aims to make the same functionality available to web applications, via various sets of interfaces. There are two key design principles at the heart of Yowl; the first is that Yowl will make use of extended functionality if it is available on different systems, such as speech, a full version of Growl, Google Gears, the Sidewinder system tray module, and so on. If the user hasn't installed any enhanced features then Yowl will still display notifications using the Yahoo! User Interface (YUI) library. This means that the author doesn't need to know what is installed on their end-users' systems.

The second design principle is that a user's settings are stored 'in the cloud', and they can take their settings from one computer to another, independent of the application that they are using (an approach we call skimming).

How to use Yowl in a web application

The first step to making use of Yowl is to load the YUI library into your web application. If you are already using YUI in your project then you may already have the functionality provided by these modules:

<script type="text/javascript" src="http://yui.yahooapis.com/2.2.2/build/yahoo-dom-event/yahoo-dom-event.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.2.2/build/animation/animation-min.js"></script>
<script type="text/javascript" src="http://yui.yahooapis.com/2.2.2/build/container/container_core-min.js"></script>

In addition to the references to YUI we'll need the Yowl library itself. Yowl currently has two scripts and a CSS file:

<script src="display-yui.js" type="text/javascript"></script>
<script src="yowl.js" type="text/javascript"></script>
<style type="text/css">
  @import url(yowl.css);
</style>

Yowl is able to make use of any number of display 'themes', and the user can decide which notifications will use which theme. The module display-yui.js is the most basic display theme, and since it's Ajax-based there will always be a way to display notifications, no matter what a user has installed.

Registering notifications with Yowl

To make use of Yowl, a programmer first needs to tell Yowl about the notifications that their web application will be sending. This is done by calling the register() function with a list of notification 'names', and then ensuring that the same name is used when making the actual notification call, later on. Since the user can enable and disable the notifications as they choose, the call to register() will also indicate which of the notifications should be enabled from the start.

As well as listing all possible notifications, registration also informs Yowl of the name of the application, and optionally provides a graphic that will be used in any notification that doesn't provide its own.

A sample initialisation call might look like this:

document.Yowl.register(
  "facebook",
  [ "Friend logged on", "Friend logged off", "Friend twittered", "Important announcement" ],
  [ 0, 3, "Friend twittered" ],
  "facebook.gif"
);

Note that the list of notifications to enable (the third parameter) refers to items in the array in the second parameter, and reference can be made either by name or zero-based index. In this example the notification at index 1--"Friend logged off"--is not enabled at the beginning, although this doesn't prevent the user from enabling it later.

Displaying a notification

Once a list of notifications has been registered with Yowl then any number of calls can be made to display one of the registered notifications. Whether Yowl will actually display the notification or not will depend on whether the user has chosen to override the default settings provided in the call to register(). Similarly, how the notification is displayed will depend on both the parameters set by the programmer in the notification call, and the values configured by the user.

A typical request would look like this:

document.Yowl.notify(
  "Friend logged on",
  friend.fullName + " has logged on",
  friend.foreName + " has just logged on, so why not talk to them.",
  "facebook",
  friend.image,
  false,
  0
);

This call asks Yowl to display a notification called "Friend logged on", which is the first in the list of notifications registered with the previous call. Provided that the user hasn't disabled the notification then the second parameter will be used as the title of the message, and the third will be the actual message itself. The fourth parameter is the name of the application, and this is used to pick up the default style for the message and a default icon if needed. In this case an image is provided--in the fifth parameter--but it could have been set to null.

The sixth parameter indicates whether the notification should be 'sticky' or not, which simply means that the user must click it before it will disappear (normal behaviour for a notification is to fade away after a set amount of time--itself configurable by the user). Note that setting the 'sticky' value to true in a call to notify() still might not make the notification sticky if the user has overridden the value in their settings. (And of course the converse is true; a user can choose to make some notifications sticky if they want to ensure they don't miss them, even if the programmer has set them to non-sticky.)

The final parameter indicates a priority level, ranging from "very low" through to "emergency". This is usually left at zero to indicate 'use the default', which gives the user more control.

In the demo application (which should work in Firefox, Safari and Internet Explorer) we've simulated a user configuring their notifications in such a way that all notifications of type "Important message" must be clicked before they disappear, i.e., they are 'sticky'. In addition, these notifications have been given priority "emergency" (with red text, in this case):

Additional display themes

There are two ways in which Yowl supports additional themes. The first is to add different styles and layouts, but use an existing mechanism, whilst the second is to actually add new mechanisms, such as speech, email notifications, and so on.

The first technique is illustrated in the demo above, since some messages use the "plain" theme (which has a grey background and thin black border) and some use the "smoke" theme (which has a black background with white text, and no border).

An example of the second type--adding additional mechanisms--is illustrated when a user has the Sidewinder system tray component installed. When this is available, notifications can be made to appear outside of the main browser window, without the need for the programmer to make any changes to their web application:

Note that if you run the demo application without installing the additional component, or run it with a browser /operating system combination that doesn't support the component, Yowl will fall back to the normal notifications as illustrated in the first demo.

Yowl: An open source centralised notification system

2007-06-19T22:05:00.000Z

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.

RDFa hacking at Hack Day

2007-06-15T19:16:00.000Z

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.

XForms custom controls, using XAML and Silverlight

2007-05-30T20:48:00.000Z

The title of this post may sound like an attempt to squeeze as many buzzwords as possible into one line, but I'm genuinely excited by all of the technologies mentioned. Everyone knows that Microsoft's commitment to standards such as HTML and XForms is legendarily lacking, and this is nowhere more obvious than in the quaintly kludgy XAML. But that said, there are some very interesting ideas in the language structure itself, and it's clear that they have done a very impressive job with Silverlight.

So whilst we're certainly not planning to water down our belief here at formsPlayer that standards are (usually) a good thing, we've never seen anything wrong with a pragmatic approach that uses whatever language gets the job done. Having said that, if it's possible to encapsulate non-standard languages like XAML--or even UI-specific languages like SVG--then we will always try to do that.

Which is why we've created a new section on the formsPlayer site for custom controls, and added two new tutorials. The first shows how easily custom controls can be built with XAML and Silverlight, whilst still maintaining a clean separation between the forms that use the controls, and the controls themselves. A second tutorial shows how to create a simple map control, which inherits from an image control.

Using custom controls to more clearly represent different types of data is an important part of our approach to XForms, but at the same time it's important for us to ensure that exciting new technologies such as Silverlight can be used with XForms and formsPlayer. These tutorials make a start, and they'll be followed by a lot of other custom control work in the coming months.

XTech goes up a gear

2007-05-19T19:42:00.000Z

I don't know if it's just my perception, but this year's XTech seemed to go up a notch in terms of content, organisation, and just general, 'place-to-beness'. Obviously a lot of this will be to do with the interesting things that are going on the world of the internet, but even so, good things must be happening with XTech, to make presenters choose to air their ideas there. There were many sessions that I wanted to attend, which isn't always the case at conferences, and although I often found the short 45-minute format a little too short, on reflection I realised that this was exactly why there was so much variety, and plenty to see.

Although I'm sure it won't last forever, one other aspect of the conference that is quite good is that it is fairly small, which coupled with the fact that there are only four sessions at a time means that you were sure to get at least 35-40 attendees to any session. (Of course, many attracted more.)

I have to mention one last thing which never fails to impress--the cool, calm and collected presence of XTech's organiser, Edd Dumbill. Putting aside the inevitable wireless connection issue, the conference seemed to me to run flawlessly (my guess is that the only conferences that actually do have wireless internet access are those organised to discuss wireless internet access). And yet on one morning, just before the start of a session, I came across Edd, deep in conversation, and seated at a table that was heaving under the weight of a rather impressive looking breakfast. Edd looked to all the world like he was on a thoroughly enjoyable holiday with some close friends, which is surely the secret of good organisation.

Skimming, and an Open Source project for a GData XForms client

2007-05-01T15:51:00.000Z

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.

Dynamic user interfaces and XForms' performance

2007-04-09T12:02:00.000Z

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.

formsPlayer provides support for Selenium automated testing tool

2007-03-26T12:11:00.000Z

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.

Kurt Cagle on RDFa

2007-03-20T23:12:00.000Z

As always Kurt Cagle makes interesting points, this time in a round-up of what to watch out for in XML technologies:

Similarly, I suspect that while RDFa may have a fairly major hill to climb in terms of adoption, it will likely end up becoming integral to the semantic web fairly soon. Folk ontologies (or folksonomies, as some have referred to them) are not in fact really ontologies at all - they are instead simply property associations. If you can articulate a consisten (sic) property relationship using attributes outside of the normal XHTML ones, then you can do more than simply tag a document - you can in fact create relationships between entities in an XHTML document without having to leave the context of that document. That's what RDFa does. These can then be interpreted by RDF enabled tools, making it possible to achieve something of the holy grail of the semantic web - provide a simple way of nonetheless encoding metadata into a document. I've argued for years that RDF as it exists right now is too complex for your average web developer, and what's more it perforce requires duplication of content between the RDF and XHTML (or whatever document format you're using). Eliminate this need for duplication by embedded the descriptive relational characteristics directly in the element's attribute set, and all of a sudden the Semantic Web begins to move away from being unachievable to being doable.

This is exactly what motivated the creation of RDFa.

Adriaan de Jonge on XForms and RoR

2007-03-20T10:21:00.000Z

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.

Tech Talk at Google on Sidewinder

2007-03-14T22:01:00.000Z

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.

Python RDFa parser

2007-03-09T05:49:00.000Z

Nathan Y. Yergler, a senior software engineer at Creative Commons has published RDFaDict, an RDFa parser written in Python.

XForms is coming of age with version 1.1

2007-02-25T22:07:00.000Z

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.

mashup* punch-up round-up

2007-02-23T16:56:00.000Z

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.

Using RDFa in XHTML 1

2007-02-20T12:58:00.000Z

One of the things I'm hoping to show on Thursday is that it is possible to embed metadata into XHTML 1 documents using RDFa today. This is an important part of the RDFa story, but it is unfortunately being lost a little. The reason for that is understandable; RDFa originated in work I was doing in the HTML Working Group on 'metadata within XHTML 2', and as a consequence many of the early examples show RDFa being used in this as yet unreleased version of XHTML. But RDFa was always intended to be a technique that would allow metadata to be placed into any mark-up, from SVG to MathML...and of course, through to XHTML 1 itself.

HTML and metadata

The main reason that RDFa fits neatly into XHTML is that it builds on the already existing semantic features available in HTML 4.01. For example, it is already possible in HTML to indicate that a document was written by some author, indicate the document's licensing level, and so on, as shown here in the XHTML 1 equivalent:


<head>
  <meta name="author" content="Mark Birbeck" />
  <link rel="license"
   href="http://creativecommons.org/licenses/by/2.5/" />
</head>

RDFa builds on this syntax by firstly making it clear what this syntax means, and secondly by extending the syntax to allow namespace prefixed properties. For example, we might use Dublin Core and Creative Commons as a source of well known properties for the mark-up we just saw:


<head>
  <meta name="dc:creator" content="Mark Birbeck" />
  <link rel="cc:license"
   href="http://creativecommons.org/licenses/by/2.5/" />
</head>

The link element uses the rel and rev attributes to indicate the nature of a connection between two documents--often things such as stylesheets, ATOM end-points, and so on:


<link
 rel="service.post"
 type="application/atom+xml"
 title="XForms and Internet Applications - Atom"
 href="http://www.blogger.com/feeds/8029070/posts/default"
/>
<link rel="stylesheet"
 type="text/css"
 href="http://www2.blogger.com/css/blog_controls.css"
/>

But what is often forgotten is that in HTML these attributes are also perfectly valid on the a tag. For example, if we wanted to indicate that an anchor in a calendar item was actually providing a description of the event, we might do this:


<a
 rel="cal:description"
 href="http://www.vecosys.com/2007/02/14/what-comes-next-web-30-preparing-for-semantic-web/"
>
 What comes next Web 3.0 - preparing for semantic web?
</a>

You'll see from these examples that there is a large amount of similarity between link and a, and that although link is used in the head of the document and a in the body, both use rel, rev and hrefto specify much the same thing--a relationship with another document. Interestingly, although the main difference between the two elements would appear to be that a allows a user to navigate from the first document to the second by clicking the label, even this is not so clear-cut; browsers such as Opera, for example, will display the labels from links that are defined in the head if they use a @rel value that it recognises. An example of such mark-up might be:


<head>
  <link rel="next" href="next.html" />
  <link rel="prev" href="prev.html" />
</head>

The class attribute

In addition to the meta and link elements, and the rel/rev/href combination of attributes, HTML also provides the class attribute as a semantic hook.

The original intention of @class was as both a style selector, and a general-purpose 'tag' for the element. Although good programming style has always been to use values for @class that reflect the purpose of an element, this is coming much more to the fore in recent years, with a clearly discernible vogue for 'semantic mark-up'.

RDFa also uses the class attribute, but extends it by allowing namespace prefixed values, just as in @rel, @rev and @property. Continuing our calendar entry, the class attribute can be used to indicate the 'type' of the item that we're dealing with:


<div class="cal:Vevent">
  <a rel="cal:description"
   href="http://www.vecosys.com/2007/02/14/what-comes-next-web-30-preparing-for-semantic-web/"
>
   What comes next Web 3.0 - preparing for semantic web?
  </a>
</div>

Properties for text

Whilst a can be seen as the equivalent in body, for the link element in head, there is no equivalent to meta for use in the body.

It may not be immediately obvious why we would want such a feature, i.e., why we would want to be able to indicate textual metadata in the body of our documents. And it's certainly true that we don't gain extra functionality; in fact we could achieve everything we need using meta in the head. But one of the key ideas behind RDFa is the notion that if the Semantic Web is ever to become a reality, it needs to be easy for people to create metadata, and perhaps the easiest way to do that is to augment an ordinary XHTML 1 page. So if we're going to get people to add metadata to their pages, we need to tackle one of the most annoying aspects of current mark-up, and that is the constant need to repeat content that is playing the role of both data and metadata.

Don't repeat yourself

For example, say we have a blog entry that has the following metadata:


<head>
  <meta name="dc:creator" content="Mark Birbeck" />
  <meta name="dc:date" content="2007-02-15" />
</head>

The chances are that the blog itself will begin with exactly the same information, but in a more human-friendly style:


<head>
  <meta name="dc:creator" content="Mark Birbeck" />
  <meta name="dc:date" content="2007-02-15" />
</head>
<body>
  Posted by Mark Birbeck on February 15th, 2007.
</body>

If we could 're-use' the string "Mark Birbeck", then we could avoid the unnecessary repetition in the author's metadata. The RDFa property attribute provides just such a way to create the same data in the body that a meta tag would have created in head:


<head>
  <meta name="dc:date" content="2007-02-15" />
</head>
<body>
  Posted by <span property="dc:creator">Mark Birbeck</span> on February 15th, 2007.
</body>

RDFa actually mirrors the way that the attributes from link can be used in the body, by making the content attribute (from meta) available throughout the document. However, it was thought best not to take @name along too, since when that attribute is not on a meta element, appearing on another element, it is difficult to know what it means. Instead we created a new attribute called property.

If we look at the steps we have gone through so far, prior to the addition of this attribute everything we have seen has been standard XHTML 1 (a, link, @rel, @rev, @href, @class, etc.). In other words, RDFa simply draws attention to the semantic features that we already had in HTML, as well as giving an interpretation to those things that are unclear. But to gain an equivalent for meta in the body--that is, something that reflects how it is used in the head--new rules were needed. It's these extra rules that sometimes lead people to think that RDFa is a language that can only be used with XHTML 2, but in fact the presence of the extra attributes doesn't stop RDFa being used in today's XHTML 1, even when viewed in today's browsers.

To illustrate the use of RDFa in XHTML 1--i.e., independent of XHTML 2--we'll use a previous post describing a forthcoming meeting about the Semantic Web. In it I've embedded some RDFa that describes the meeting itself. We saw a cut-down version of this RDFa earlier, when looking at @rel with @href on an a tag, and it looked like this:


<div class="cal:Vevent">
  <a rel="cal:description"
   href="http://www.vecosys.com/2007/02/14/what-comes-next-web-30-preparing-for-semantic-web/"
>
   What comes next Web 3.0 - preparing for semantic web?
  </a>
</div>

But the real version does exactly what we have been discussing, and re-uses the text inside the anchor to provide the cal:summary value, by using the new attribute property:


<div class="cal:Vevent">
  <a rel="cal:description" property="cal:summary"
   href="http://www.vecosys.com/2007/02/14/what-comes-next-web-30-preparing-for-semantic-web/"
>
   What comes next Web 3.0 - preparing for semantic web?
  </a>
</div>

This post lives on Blogger.com and is delivered to all sorts of browsers, yet the use of the additional RDFa attribute causes no problem at all. But the advantages of being able to augment the mark-up in such a way means that an RDFa parser--whether running on a server or inside the user's browser--can make use of this information in all sorts of ways.

We've seen how adding the property attribute allows us to 'not repeat ourselves' when used with XHTML 1, and still allows the document to function normally. Now we'll see another attribute that RDFa adds to solve the problem of adding metadata about many different resources at the same time.

Multiple resources on a page

RDFa provides another attribute to HTML, called about. The reason it's needed is that many documents on the web today contain multiple 'items' and a great deal of metadata about those items. This means that simply using link and meta in the head of the document is not enough for these kinds of documents, since placing metadata in head only tells us about the document itself, and nothing about the various pieces of content within the page.

A simple example would be a blog page, where each individual post needs to have its own metadata. Although the basic metadata features in HTML aren't sufficient, by using the RDFa about attribute we can change the 'target' for some of the embedded metadata. For example, we might have two blog entries on the same page, like this:


<div>
  <h2 property="dc:title">What I did on my holidays</h2>
  Posted by <span property="dc:creator">Mark Birbeck</span>
  <div>
    First, we got on the plane...
  </div>
</div>
<div>
  <h2 property="dc:title">Looking forward to going on holiday</h2>
  Posted by <span property="dc:creator">Mark Birbeck</span>
  <div>
    It will be lots of fun...
  </div>
</div>

As things stand, both sets of metadata--dc:title, dc:creator, and so on--will only tell us something about the document as a whole. But by using @about we can 'localise' the metadata to refer to only one part of the document:


<div about="#post-2">
  <h2 property="dc:title">What I did on my holidays</h2>
  Posted by <span property="dc:creator">Mark Birbeck</span>
  <div>
    First, we got on the plane...
  </div>
</div>
<div about="#post-1">
  <h2 property="dc:title">Looking forward to going on holiday</h2>
  Posted by <span property="dc:creator">Mark Birbeck</span>
  <div>
    It will be lots of fun...
  </div>
</div>

(Bob DuCharme has a discussion of his use of RDFa with Moveable Type.)

Another example would be a site that has lots of different media on one page; for example, Flickr has many images per page, and each image can have different licensing information, a different photographer, different tags, and so on.

The main point is that the HTML metadata story has needed 'beefing up' for a while if it was to cope with the changing nature of the web, and being able to handle complex pages of the kind we've just illustrated; RDFa has provided the necessary additional metadata features to cope with this.

To close our running example of a calendar entry, the finished mark-up would look like this:


<div about="#talk" class="cal:Vevent">
  <a rel="cal:description" property="cal:summary"
   href="http://www.vecosys.com/2007/02/14/what-comes-next-web-30-preparing-for-semantic-web/"
>
   What comes next Web 3.0 - preparing for semantic web?
  </a>
</div>

With the about attribute, this pattern could be repeated many times within a page, once for each available event.

Schemas for validation and document creation

Perhaps the most interesting development for RDFa in the context of its relationship to XHTML 1 is the forthcoming release of some XML schemas that conform to the guidelines in XHTML Modularization 1.1. These will be used to create a dialect of XHTML that includes both XHTML 1 and RDFa, and therefore means that a document that uses RDFa can be validated. The schemas will even allow XML editors to guide the editing process.

Conclusion

RDFa can be used now in XHTML 1, and provides an efficient, easy to learn, generic solution to the problem of embedding metadata in XHTML documents. By leveraging the already existing HTML features found in XHTML 1, RDFa provides a gentle on-ramp. But by adding to these basic features support for namespaces, and some additional attributes to cope with documents that contain many resources, RDFa provides everything that is needed for incredibly complex documents. If you're interested in making a start on RDFa, there are a number of entries in this blog that are tagged with 'rdfa'. You'll also find rdfa.info a useful resource.

New drafts of XML Events 2.0 and XHTML Modularisation 1.1

2007-02-19T12:07:00.000Z

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.

Jon Udell on Microformats and RDF...time for RDFa

2007-02-16T20:58:00.000Z

I made the following comment on Jon's latest post:

You say:

Perhaps we’ve been looking in the wrong places for the first microformat to achieve liftoff. Many of us hoped hCalendar would, but it’s hard to argue that it has. I suppose that’s partly because even though we have a variety of online event services that produce the hCalendar format, there just aren’t that many people publishing and annotating that many events.

I think this misses the point; the problem with hCalendar is not that there isn't enough data...there's plenty! The problem lies in the general lack of coherence of microformats. You can't take a collection of non-integrated things and call them a standard simply by giving them a common moniker. But that unfortunately is what microformats has done (and makes a virtue of it!).

The result of doing this, is that this week you have to write an hCalendar parser, next week you have to write an hCard parser, the week after you haven't got time to write a parser because you are too busy trying to convert FOAF to hFOAF, and then the following week you have to define how all the microformats you have so far are to work together, just in time to start all over again with the next format (which incidentally involves you in learning about chemistry). In short, it's a technology that does not scale.

RDFa on the other hand, has confronted the issue of creating a generic syntax for putting metadata into HTML right from the start, because that was it's whole raison d'etre. Once you have written one RDFa parser, you need write no more, unless of course you want another for a different platform. And you don't need to go around converting RDF vocabularies as microformats does, since RDF is used directly. (Note that I'm specifically saying that RDF is used, and not RDF/XML. RDFa uses the idea of representing metadata with triples--such as [this document] [written by] [Jon Udell] or [this document] [published on] [Thursday], etc.--but it doesn't use the tricky and complicated RDF/XML syntax to represent those triples.)

The whole point is that by providing general rules, any vocabulary--available now, or coming in the future--can be used directly in an HTML document.

So whilst microformats don't scale, RDFa absolutely does. And crucially, by being able to use and mix already existing vocabularies without conversion, RDFa retains the de-centred model that the web has thrived on.

Mash-ups

And this de-centred model is also what mash-ups are all about; the mash-up lift-off you've waited for hasn't happened because in order to do even a simple mash-up with calendar and people info that is based on microformats, we have to write two parsers, and then work out how the two sets of data co-exist on the page. In short, we're trying to work with inherently de-centred mash-ups, using the highly centralised microformats.

RDFa returns us to the decentralised nature of HTML (anyone can link to anything) and the decentralised nature of RDF (anyone can make statements about anything) and leverages the two--"bridging the clickable and semantic webs".

Blatant plug

Anyone who is in London next week might find the following meeting on the Semantic Web of interest:
http://internet-apps.blogspot.com/2007/02/presenting-rdfa-at-what-comes-next-web.html
There will be four speakers including me, and I'll be using my spot to explain RDFa, and do some demos.

Presenting RDFa at "What comes next Web 3.0 - preparing for semantic web?"

2007-02-16T10:37:00.000Z

Sam Sethi has invited me to talk about RDFa, formsPlayer and Sidewinder at an interesting meeting in London next week. It's called What comes next Web 3.0 - preparing for semantic web?. It's organised as part of a series going under the title of mashup*, and as well as myself, the speakers are Hugh MacCleod, Paul Walsh and Tony Fish.

Excellent introduction to RDFa

2007-02-15T14:53:00.000Z

I'm trying not to make this the shortest blog post in history, but the title says it all, so the only thing left is to provide the link. I guess I could add that it's written by Bob DuCharme, but you would have found that out when you went to read it.

Understanding the XForms dependency-engine

2007-02-13T00:28:00.000Z

At the heart of an XForms processor is an incredibly powerful 'dependency-engine'. It works much like a spreadsheet, in that you tell it what calculations you want performed, and then the processor works out when to do them, based on changes that take place in the data in the form, as the user interacts with it. Although this all happens automatically--just as in a spreadsheet--knowing what's going on 'under the hood' will mean an XForms programmer can avoid writing inefficient code.

To help programmers gain a better understanding of this little-discussed part of XForms, I've added Understanding the XForms dependency-engine to our Programming with formsPlayer and XForms handbook.

Comments would be most welcome. :)

formsPlayer.com updated--the first place for XForms programmers

2007-02-09T17:12:00.000Z

We've been working hard in the last few months on a number of different things. Some are imminent--such as full support for XForms 1.1 in formsPlayer--and some are almost imminent (and we can't talk about them yet). But one that is here now, is the fresh, new, restructured and redesigned formsPlayer.com site.

Thanks to an excellent Polish designer now working in Ireland, who was introduced to me by an Englishman who we worked with on a project for a Canadian customer, formsPlayer.com now has a new look. And I don't mind saying, I think it looks great...thanks Bartek!

Up-to-date

The main change in the site is that being based on Drupal, it is now much easier for us to update, which means that we can add tutorials, samples, articles and blogs whenever the mood takes us--and that's often. We've also moved our bug-tracking onto the site, and of course there are plenty of forums in which people can ask (and answer) questions, as well as share ideas.

Integrated

One of the main advantages of the new site is that everything is completely integrated; a comment in the bug-tracking system can link to a tutorial, a blog entry can link to sample code, an answer in a forum can link to a feature request. Being able to cross-reference everything means that the information and knowledge in formsPlayer.com, about building web applications with XForms, will get deeper and deeper.
With these changes we will continue to make formsPlayer.com the foremost place to go for XForms software, samples, tutorials, forums, and more.

An XForms toolbar for searching the Prototype API documentation

2007-02-05T03:10:00.000Z

A recent announcement that documentation for the Prototype Ajax library was now available was followed almost immediately by a rather neat looking desktop gadget and a Firefox sidebar. Not to be outdone, I decided to put together a toolbar for Internet Explorer, and managed to do the whole thing with one XForms form control and an action handler--and of course, no script.

If you use Prototype and you just want to install the documentation toolbar, you can do so from here. You'll need formsPlayer, but this form will install it automatically, and once you have it you'll be able to add other bars to IE without any further downloads.

I've written the whole thing up as a tutorial which might prove interesting even if you don't want to create any toolbars, as it shows different ways to use load, as well as DOMActivate on an input control. If you'd like to get the code and use it as a guide to creating your own toolbars, it is available from here.

Evaluating XForms in 23 hours

2007-01-31T10:33:00.000Z

I left a comment on a blog about XForms recently, and since it never made it past 'moderation' I thought I might as well reproduce it here.

The story begins on January 28th, 4:46pm when Project Timelines was published. The post ends with:

Other projects to check out

jQuery, XForms

The following day, at 3:05pm, we get another post, this one called XForms = CRAP. It's short, so I'll reproduce the entire thing:

XForms is touted as the latest W3C standard for XML form filling, with syntax that allows for case/switch/conditionals.

However, support is sketchy at best, and worse is instead of using code to write stuff such as

if txtUserName.Text = “” then

end if

we have to use < xml >
nonsense

Plus the IDEs out there to simply this is simply not available. With Microsoft not supporting this one, choosing to go with InfoPath for its own XML based forms, this will turn out to be a dud.

File this off for at least another 2 years before we revisit this one =)

I don't have a problem with people saying what they like about anything they like--in fact that is to be encouraged! But equally, I feel strongly that if you do publish your ideas, you should expect comment on them. In this particular case we have a post that creates a negative atmosphere around XForms but based on nothing that you can put your finger on. I confess to getting a little riled at the obvious lack of research, and the tone adopted by the self-proclaimed expert, and here is the text of the comment that I tried to leave:

Wow! That was quick. Only yesterday you had XForms in your list of things to check out (along with JQuery), and today you've completed the task. In *under* 24 hours you’ve finished evaluating XForms, and concluded that support is "sketchy".

Yet our product formsPlayer supports the entire standard and is being used by numerous companies, ranging from HP in Italy through to Tyco, to a large oil company. They use it embedded in IE, but formsPlayer and XForms are also being used by a building society in this country, embedded in a .NET application, running on Tablet PCs.

In addition to that, you'll find that the Firefox plug-in is almost complete, and that the Orbeon XForms engine, which processes XForms server-side, as well as providing sophisticated pipeline processing functionality.

In other words, support is far from "sketchy", and even in as little as 24 hours you should have been able to see that.

In that same 24 hours you've also got to the crux of the declarative v. procedural programming debate that has run for years; you've cut through the discussion, and clarified the most important point--that instead of having an 'if' test on a string, we have to use XML "nonsense".

Incredible.

All the best,

Mark

PS Don't take this too seriously, I'm just pulling your leg...but you have to admit, these are pretty bold claims you are making, especially when you file them under "Architecture of Systems".

There...I'm feeling better already.

Interviewed on XForms for cubicgarden

2007-01-19T23:59:00.000Z

Yesterday, myself and Phil were invited by Brendan Quinn to talk about XForms over at the BBC. Since we had no idea what experience people might have of XForms, we began with the XForms and Internet Applications presentation, and then did some demos and a bit of 'view source'.

The presentation included a demo that searches Amazon for books, which we followed with other samples from the formsPlayer.com samples page, such as a Flickr search, Google Maps, Microsoft Virtual Earth, and more.

As it turned out, there was some familiarity with XForms, and there were some excellent questions. Although we tried to answer all of them, we also recommended our tutorial, Introduction to XForms. It covers a lot of material, and walks through how to create two forms; one that that saves bookmarks to del.icio.us, and another that searches Flickr.

After the meeting, Ian Forrester interviewed me about XForms and where it was going, and we ended up talking about web applications, Apollo, Sidewinder, the W3C and innovation, XAML, non-obtrusive Ajax, xforms.org...and whether Kurt Cagle backing XForms is an indicator of future success, or not!

RDFa, chemistry and the sharing of knowledge

2006-12-19T10:28:00.000Z

(This post appeared first on the http://rdfa.info site.)

When most of us think of blogs we think of people writing about fairly personal things, perhaps to do with their families or hobbies. At a push we might acknowledge that many bloggers will be writing about technical issues such as some trick they developed to get CSS to work in all browsers, or how to build a web-site with Ruby on Rails, Ajax or XForms.

But have you ever thought whether Marie Curie would have a blog, if she were carrying out her research today? It would be unlikely to contain information about what she was cooking for Christmas lunch, and far more likely to be like a live notebook of her results and working outs as she became the only person ever to win Nobel prizes in two different disciplines (chemistry and physics).

When it comes to the development of new knowledge the chance of significant breakthroughs is increased if knowledge is easy to share, particularly across disciplines. The internet provides an enormous opportunity to share knowledge across the world, and RDFa has a role to play here.

This thought struck me when reading Egon Willighagen's blog which includes items about his use of RDFa to include metadata about his chemistry research. Here we have an exciting convergence of technologies; he uses Blogger.com to allow him to easily publish and manage his writings, and he is experimenting with using RDFa to provide metadata about the chemical compounds he refers to in his work. With this additional metadata two things are possible. First, the user experience is improved when accessing the blog (he talks of showing pictures of the molecular structure of a chemical when a user hovers over the name, for example), and second, the search experience is also improved; now a search could potentially yield documents 'about' the chemicals referred to, rather than other, non-specialist documents.

This is an exciting use of RDFa, and shows the benefit of recognising that there is a demand for the co-existence of different (sometimes specialist) vocabularies within the same document. Over the coming months I think we'll see more of these kinds of use cases.

Bill Gates, webapps, and XPointer

2006-12-14T21:17:00.000Z

Liz Gannes got to meet Bill Gates at Microsoft's headquarters, as part of a day spent with "leaders in various aspects of the web community". Ah, yes...the web community. Anyway, Liz's report (Bill Gates on the Future of Web Apps) makes interesting reading because she asks an intriguing question of Gates, and gets a resonable reply:

We each got to ask Gates one question. I asked which applications he forecast to live within the browser and which outside of it. He replied that the distinction would come to be silly from a technical standpoint, but that the necessary movement toward web APIs does present challenges on the business side.

This whole thing has sparked a lot of discussion, but much of it seems to me quite old-fashioned. "What should go in the browser and what in a desktop application" is (or should be) a strange question to ask, and as Gates says, it's just "silly" from a technical standpoint. But I would add a further dimension, which is that I think it's also silly from a user's perspective, since they should be able to decide based on the task at hand.

Browsers v. desktop applications

Whilst the browser is certainly a useful application for following your nose and saving references to some of the places you've been, a desktop application has the advantage that it can be controlled independently of other applications, has no clutter like address bars and big buttons that are not relevant to some specific task in hand, can be left open all day--perhaps docked to an edge of your desktop, auto-hiding when you move the mouse away--and could even be partly transparent, so that it takes on some odd shape.

So given that standalone desktop applications are preferable for just about every task other than surfing the web, why shouldn't we be able to take any HTML pages that we find useful, and run them as if they were purpose-built desktop applications? There are plenty of pages out there that don't look great, but do useful things like show us the times of the next trains at your local station; we should be able to take the URL, wrap it in an application container, and let it sit on the desktop.

And further, by running that container from the command-line, we could open any number of these 'desktop web applications' with shortcuts or batch files. In fact, why not pass parameters on the command-line so that we can even control the position and size of the window, its docking and auto-hide behaviour, its transparancy and opacity, and so on.

And as you might expect, this is exactly what we've done with Sidewinder.

Sidewinder as a web applications viewer

For a while now we've been able to give Sidewinder a URL on the command-line and make it load and render the document referred to. It doesn't matter whether the document exists on the web or locally, Sidewinder will initialise itself with the file. (Sidewinder not only supports the loading and executing of XHTML documents, but it will also run 'pure' JavaScript files.)

But to set the location and size of the window, or its docking and transparency properties, we normally had to add metadata to the head of the document, or create a JavaScript webapp. No more. A couple of days ago we added the ability to set the metadata properties when loading the document.

Command-line parameters v. XPointer

The obvious way to do this would have been as part of the command-line, in the usual way:


swviewer2 -h600 -w1000 -position=top http://somepage

But we decided against this because we also wanted to be able to load our applications from links in web pages. Instead we decided to use an XPointer approach (see XPointer Framework). For example, to open the Adobe Flex Flexstore application in a window that is 1010 by 610, is docked to the top edge, and auto-hides when you move the mouse away, we just type this into the command line:


swviewer2 http://examples.adobe.com/flex2/inproduct/sdk/flexstore/flexstore.html#meta(width=1010,height=610,position=top,anchor,autohide)

I guess that's a lot to type, but it's easily placed in a desktop shortcut, or even better, placed in a batch file along with a reference to Gmail, GCal, Windows Live, GDocs and whatever else you find yourself loading into a browser every day to help you function.

Conclusion

Bill Gates is exactly right that the boundaries between web applications and desktop applications will continue to blur, and that if it isn't already pointless to make the distinction it soon will be. The whole raison d'etre of Sidewinder is to blur that distinction as much as possible, and we're going to keep experimenting with new ways to do this.

You can read more on our skimstone site: we have a 'how to' that shows the Adobe Flex Flexstore demo running as a desktop application, with some screenshots if you don't want to install anything:

But if you do install Sidewinder you can try exactly the same approach yourself, and load any of your favourite web-sites as desktop applications...all without programming.

When should I use XForms?

2006-11-22T10:34:00.000Z

The question about how XForms should be sold to customers often comes up, and generally we reply "why would you?". As in any IT project you need to use the right tool for the job, so why would you try to sell XForms in and of itself? Sometimes XForms is the right thing, and sometimes not, but either way--we say to those who ask--it's a tool in your armoury (if you want to use it), not your customers'.

If you have a system that uses web services a lot (for example), then a rich client that can handle XForms will be ideal--that's where most of our use cases are coming from for formsPlayer deployment. I've mentioned before a system that we've built for a customer that involves using the OpenWFE workflow engine and the eXist XML database, and we've written practically no code on the server! All we've done is used a few workflow templates, and the REST/XQuery interface to eXist, and everything else is achieved via the XForms themselves. Maintaining such a system is not only very straightforward, but is easy to move to other platforms, as well as swap components in and out (since the interfaces--such as XQuery--are all standard). This is all at the heart of the skimming approach we've been talking about.

But unfortunately, at the other end of the spectrum, if you have a system that uses a server-side scripting language, with direct queries on a database to populate list-boxes (that whole nineties thing!) then you might not find XForms that useful. You'll have a maintenance nightmare with such an application, either way. For XForms to be of benefit in this scenario it would have to dramatically improve the user experience, rather than only being 'as good' as what you have already.

I'm not differentiating here between using client and server technologies, but rather between the use of high-level constructs versus painstakingly creating pages with server-side script. So in the approach I'm suggesting, you will also get productivity improvements if you can use a pipeline-based system like Orbeon, since it too uses 'big constructs', even though it delivers HTML to the user.

At least in the short term, the main benefits of XForms will generally accrue to the developers and not to the users, and will be of most use to those who have a service oriented architecture, rather than an old-fashioned web-site. So trying to 'sell XForms' is probably not only a waste of time, but actually unnecessary--if it fits your system, use it.

XForms and repeating structures...are they really so special?

2006-11-20T19:28:00.001Z

In one of discussions in the XForms Working Group recently, around insert and delete, we agreed with Erik Bruchez's idea that if @nodeset returns a collection of nodes then we should process all of them, rather than acting on only the first (the so-called "first node rule"). I like this, and to me it makes code easier to read; I can tell what an author has in mind if I see this:

<delete nodeset="customers/customer[1]" ... />

rather than this:

<delete nodeset="customers/customer" ... />

After we agreed to do this it made me wonder about other situations where processing the entire nodeset might give rise to different behaviour if there was more than one node, and one that leapt out was differentiating between repeating structures and non-repeating structures simply by the number of nodes in the nodeset. For example, if there is only one customer in the instance data, then this (if it were legal):

<group nodeset="customers/customer">
  <output ref="name" />
  <output ref="telephone" />
</group>

would behave the same as this:

<group ref="customers/customer">
  <output ref="name" />
  <output ref="telephone" />
</group>

If there was more than one customer, then it would be equivalent to a repeat:

<repeat nodeset="customers/customer">
  <output ref="name" />
  <output ref="telephone" />
</repeat>

But since the second case (multiple customers) includes the first case (only one customer) why bother ever using anything other than a repeating structure? If you don't want a repeat, simply add "[1]" as we saw before.

Of course the problem would be that using a 'repeat' element when you don't actually want a repeating structure would be awkward to read:

<repeat nodeset="customers/customer[1]">
  <output ref="name" />
  <output ref="telephone" />
</repeat>

or:

<repeat nodeset="customers[1]">
  <repeat nodeset="customer">
    <output ref="name" />
    <output ref="telephone" />
  </repeat>
</repeat>

But it's not so the other way round; i.e., saying that elements that use nodesets operate over all of the nodes in the nodeset is actually fairly intuitive, which leads me to wondering whether we should allow this:

<group nodeset="customers/customer">
  <output ref="name" />
  <output ref="telephone" />
</group>

in addition to this:

<group ref="customers/customer">
  <output ref="name" />
  <output ref="telephone" />
</group>

and this:

<group ref="customers">
  <group nodeset="customer">
    <output ref="name" />
    <output ref="telephone" />
  </group>
</group>

We would obviously keep the @ref format for backwards compatibility, and as a shorthand for selecting the first node. And even more interestingly, it could retain its use for setting context, for example when used in conjunction with @nodeset. For example:

<group ref="customers" nodeset="customer">
  <output ref="name" />
  <output ref="telephone" />
</group>

Using the XForms model without the user interface

2006-11-15T23:14:00.000Z

The XForms model provides a rich set of features to manage data submission, calculation dependencies, validation, control notification, and so on. Obviously it's normally used with the XForms user interface--controls such as input and range, as well as structures like switch and case or repeat--but we've recently posted a couple of examples on skimstone where a non-XForms user interface is driven by an XForms model.

The first concerns a 3D visualisation, linked to a simple XML file that contains a list of parts. XForms is used to select parts of the visualisation depending on which item in the part-list is chosen.

The second example involves a standard Google Map, with each of the pins that are overlaid onto the map coming from XForms instance data. In the examples the data is an RSS feed that contains geo data, which means the code can be used to overlay any feed onto the map.

Although our preference is invariably to wrap these types of features into reusable components that are instantiated with XBL, it's still sometimes worth showing examples like this since they provide an interesting link between XForms and Ajax.

Could DIAL just be XForms?

2006-11-03T10:51:00.000Z

If you take a look at the Device Independent Authoring Language (DIAL) Primer you'll see that the basic idea of DIAL is to use XHTML 2, XForms and a few other bits and bobs as a kind of 'abstract' language for defining documents that may then be used on many devices. Server-side processes can decide which pieces of a document to send to a client based on its capabilities, user credentials, and so on.

Now, although I'm glossing over the details, it seems to me that the key components of DIAL are a data model and some declarative mark-up that makes use of the data to switch other mark-up in and out. Here is an example from the primer:

<sel:select>
  <!-- check if the requesting user is a subscriber-->
  <sel:when expr="dcn:search('userSubscriptionStatus') = premium">
    <!-- if so select this movie -->
    <object sel:selid="HelloWorldMovie" src="HW_movie_portrait.mov"/>
  </sel:when>
  <sel:otherwise>
    <!-- if not send an image instead -->
    <object sel:selid="HelloWorldMovie" src="HW_image.jpg"/>
  </sel:otherwise>
</sel:select>

In this example only one of the two 'object' tags will be delivered to the device that has requested the document, and which of these it is will depend on the whether the user is a 'premium subscriber' or not.

But if we want a language with a data model, that supports XPath, and that can conditionally drive a user interface...we need look no further than XForms! The above mark-up could be expressed as the following XForms:

<!-- if the requesting user is a subscriber-->
<xf:group ref="userSubscriptionStatus[. = 'premium']">
  <!-- show the movie -->
  <object id="HelloWorldMovie" src="HW_movie_portrait.mov"/>
</xf:group>
<xf:group ref="userSubscriptionStatus[. != 'premium']">
  <!-- show the image -->
  <object id="HelloWorldImage" src="HW_image.jpg"/>
</xf:group>

I've glossed over quite a few things here, but the main point is that XForms is almost (but not quite) suitable, and so it would be interesting to work out what it would take to give XForms the extra capabilities it needs to act like DIAL.

XForms as a processing language

If you look at the diagram in the section How does DIAL work you see that all that is happening is that one DIAL processor is carrying out some processing and passing the results to another DIAL processor:

Each of these processors needs to be able to support a data model, each of these processors needs to be able to generate a UI based on a set of rules and the data. In other words, each of these DIAL processors needs only to be an XForms processor.

This is actually an idea I've been bouncing around for quite a while (I presented a paper called A Standards-based Virtual Machine on similar themes at the W3C's Web Applications Workshop a couple of years ago), but I'm becoming increasingly reminded of it because a number of recent initiatives that are based around server-side processing would seem to me to be prime candidates for some 'unification'. There are many features that appear at first sight to be client-side but could be usefully used on a server, and vice versa.

Declarative, Accessible Ajax with the HTML role attribute

2006-10-20T11:45:00.000Z

In XForms there is a 'hint' element, which is roughly defined as "when the user interacts in some way with the parent element of the 'hint' element, the text of the 'hint' should be made available to the user".

That might sound like a lawyer speaking, but it's purposefully vague so that the same functionality can be made available in many different types of device; the 'hint' can obviously be activated by a mouseover on a desktop PC, but it could also be activated by a long pause on a touch-tone phone system, or by navigating to the control on a voice or mobile system.

In XForms we use the 'hint' element like this:

<xf:input ref="name">
  <xf:label>Name:</xf:label>
  <xf:hint>
    Please enter your name.
  </xf:hint>
</xf:input>

But if we have this definition for 'hint', why can't we reuse it elsewhere? If some other language needs to support hints, why can't they use the same element, and the same definition? In fact, why can't an Ajax library use the same definition?

Ajax libraries

If you take a look at the way Dojo allows authors to add tooltips, you'll see code like the following:

<img id="pic" src="holiday.gif"></img>
<span dojoType="tooltip" connectId="pic">
  Me on a hat-wearing holiday, where we got to wear
  all sorts of hats.
</span>

This is just an example, and most of the main Ajax libraries support something similar.

There are two problems here; the first is that the attribute being used ('dojoType') is non-standard, so any system trying to help a blind user will have no idea what to make of the 'span'. That's a shame, since there's lots of useful text that could be made use of by a voice system.

The second problem is that even if systems were made aware of the different attributes being used by different Ajax libraries to add custom components, it would have no idea whether it could treat a Dojo 'tooltip' in the same way as a YUI tooltip. A server might know all about the functionality of the device it is delivering the mark-up to, but would have no idea whether it could replace this mark-up with something that the device understood.

One way around this problem is to simply use the XForms 'hint' element 'as is':

<img id="pic" src="holiday.gif">
  <xf:hint>
    Me on a hat-wearing holiday, where we got to wear
    all sorts of hats.
  </xf:hint>
</img>

But another way is for libraries like Dojo to support the XHTML role attribute, rather than their own attribute, and to agree on standard identifiers for common parts of a component:

<img id="pic" src="holiday.gif"></img>
<span role="xf:hint" connectId="pic">
  Me on a hat-wearing holiday, where we got to wear
  all sorts of hats.
</span>

Globally recognised roles

The first step to reusing the XForms hint definition like this, is to create a way to refer to the notion of 'hintness' without requiring the mark-up, via some unique identifier. The idea here comes from RDF, but you don't need to be an RDF expert to follow this; all we're saying is that we'd like a 'concept' of 'hinting' that everyone agrees on, and we want to identify that concept with a 'key' such as:

http://www.w3.org/2002/xforms#hint

I've just made this key up by putting '#hint' on the end of the XForms namespace, but however we arrived at a URL, we now have something that could be used by systems all over the web to identify a 'hint'.

The URL is a bit of a mouthful, so a common convention is to use QNames to shorten these long URLs; if we had 'xf' defined as the XForms namespace, we could now refer to our concept as 'xf:hint'.

I should stress one thing--assigning an identifier to our concept is not about saying that this is now the definitive definition of 'hintiness', but instead that this is one definition amongst many, and it's identified with 'xf:hint'. In effect we're saying: if hints in your language or system behave just like hints in XForms, then why not say that they are 'xf:hint' objects. But if they don't behave like hints in XForms, please use a different identifier for your types of hints.

This technique of using a URL to identify functionality is being used in the accessibility community (see Roles for Accessible Rich Internet Applications, for example).

Summary

Having a standard 'hook' for information about the purpose of a widget means that server software can make substitutions based on what the client is capable of supporting, and assistive technologies on the client-side can provide the user with a much better experience. In fact, 'role' is already supported in Firefox as a hook for accessibility (see Accessible DHTML). Of course, even if the browser doesn't do anything clever with the attribute natively, there is still nothing to prevent Ajax libraries like Dojo from using it as their hook.

For other articles on 'role' see Using the role attribute to extend XHTML and The XHTML role attribute: small and perfectly formed.)

RDFa and microformats

2006-10-12T12:04:00.000Z

During the course of writing an email recently, I needed to compare microformats with RDFa. I thought the list might be of interest to others.

Microformats

Microformats gets into real trouble when you try to combine more than one 'format' (in fact, rules of combination have to be defined);

it requires converting already existing langauges so that they work within the microformat rules--painful and slow, given that languages such as FoaF have already had an enormous amount of work put into them, and this must be almost completely repeated;

there is no notion of namespacing;

adding new languages seems to be based on a few key individuals;

there is no way to validate;

it isn't actually a "poor man's semantic web", as some suggest, since it isn't providing a generic mechanism. Instead it provides a way to hand-craft a small number of use-cases, which in turn means that some other process still has to do the work of working out what it means. For each format another 'process' will be required.

RDFa

RDFa tackles all of these issues by providing a series of general rules that can be applied to any metadata, rather than specific rules for specific formats;

be written as simply as microformats;

scale to any level of complexity;

allow QNames to be used if required, to provide full namespacing;

make use of any RDF taxonomy;

operate at the level of document structure semantics, as well as the document content semantics.

Is it AJAX, Ajax...or XForms?

2006-10-08T21:37:00.000Z

There seems to be growing agreement that what some have been calling AJAX should now be called Ajax. I'm interested in this because I've long seen Ajax as an approach rather than a specific set of technologies, and in particular, that the mind-set Ajax encourages is very much in tune with that for XForms. Since the techniques used in Ajax are in many cases a subset of the rich features available in XForms--with often the difference being that XForms takes a declarative approach whilst Ajax uses procedural scripting--I see Ajax as an incredibly important stepping-stone (or even advert) for XForms.

The Ajax upper case/lower case debate has been an interesting one, but it's great to see how quickly people have realised that they are no longer dealing with an acronym (and therefore a fixed set of technologies) but an approach (and therefore many related technologies). If Pluto can be redefined after thousands of years, 'Ajax' can certainly be redefined after only two!

But I feel confident in predicting that the next phase for Ajax (rather than AJAX) will be less about improvements in its functionality, and more about making it easier to use (there are, after all, only so many animation or drag-and-drop routines you can write). And to make it easier to use, Ajax needs a declarative language. Since XForms was designed from the ground up to solve exactly the problems that Ajax does, it fits the bill, and I see the 'renaming' of Ajax as an incredibly important step towards encouraging people to see where XForms fits in the Ajax spectrum.

I suppose I should be a little more precise, and say that actually the language we need is XForms plus XHTML (perhaps with SVG, MathML and various other standard mark-up languages thrown in). For ease, I've called the aggregate language xH, and the key idea is that mark-up can be used to build web applications. XForms provides an incredibly powerful piece of this.

XForms tips on IBM's developerWorks

2006-10-07T08:43:00.000Z

It's great to see more and more useful XForms articles popping up here and there. The latest that caught my eye are a trio of 'tips' from Nicholas Chase, over on IBM's developerWorks site. The first concerns using a Java servlet to process data from an XForm whilst the second does the same job with PHP. The third--on combing XForms and Ajax--could perhaps have done with pointing out that XForms doesn't just contain one or two Ajax features...it's a superset of Ajax, without the spaghetti! XForms is Ajax 2.0.

One last link worth mentioning; if you use Perl, you might find Tyler Anderson's article useful.

The best of XTech 2006!

2006-10-06T22:17:00.000Z

Edd Dumbill is a busy man, at the centre of a lot of things. If he's into an acronym you know that firstly it's going to be good, and secondly it will one day be big. (The fact that he seems to like RDF, for example, gives me hope.)

So I'm more pleased than I can describe to discover that a recent blog of Edd's, which listed some of the "best received presentations" from XTech 2006, included my presentation on RDFa, and Steven's on declarative programming. I'm excited about the possibilities for both of these ideas over the next couple of years, so it's a real boost to see someone of Edd's experience and influence giving them a mention.

XForms, REST, XQuery...and skimming

2006-09-27T09:48:00.000Z

I had a very pleasant day out of London yesterday, over at the CCLRC Rutherford Appleton Laboratory near Didcot. The event was a joint meeting between XML UK and the W3C Office for UK and Ireland, and the topic was XML Access Languages. The main idea was to look at the various W3C languages that can be used to query and manipulate XML, from XPath and XQuery, through to XSLT, and on these topics we were lucky to have both Liam Quin and Michael Kay.

In addition to looking at the current and future state of these languages (including Andy Seaborne's dip into RDF-world via SPARQL), there were also two presentations on how they might be used in the context of building web applications. One of them was mine, looking at how if we push more and more functionality into the client--whether an Ajax or XForms client--and then access our data using XQuery over REST, we can build web applications much more quickly, and they are easier to maintain. Chris Wallace followed this by showing a full application that uses Ajax and eXist, and obtains data for all sorts of purposes, such as for transfer into Google Earth.

Skimming

The main focus of my talk was what we've called skimming; the idea is to be able to install various pieces of server-side software and then not have to touch them again! No configuration...no writing of server-side scripts...just store some data and retrieve it. If you've not looked at this idea before, then it may sound a little odd, but a good example of a component that can do this would be a WebDAV server; here you simply install the software and then start saving documents, editing and updating them, searching for them, and so on. There is no reason why you couldn't build an entire client-side application that manipulates documents and stores and retrieves them, without having to do any more to the server than install the WebDAV software.

The XML database eXist can be much the same as WebDAV in that you can install it and then immediately start punching XML documents, but unlike relational databases you don't need to know in advance what you want to store--no need to create tables first, define schemas, etc.

But the skimming architecture goes further; by using a standard interface to our data--in this case XQuery--we don't need to write server-side scripts, applications or servlets to manage the data. Instead we just use queries from our 'rich client'. The resulting application is very loosely-coupled, and can run on just about any server-side architecture; client-side forms can be deployed by any HTTP server because there is no scripting involved in their creation, and the data can be delivered by any XML database that supports XQuery--and the list of those is getting longer.

So my presentation was about using REST, XQuery and XForms to allow for the rapid development of rich internet applications, by defining the application's behaviour on the client, and then using 'vanilla' software on the server.

Update

I've just seen Bill Higgins' Ajax and REST, Part 1 which is a fantastic explanation of exactly the issues I'm experimenting with. His article is just as applicable to XForms as Ajax...as you read it, for every occurrence of the word Ajax just replace it with the word XForms. :)

Update 2

And now I've come across the blog the DIL, which the author is going to use to document their experience building new systems and user interfaces. One paragraph in particular caught my eye (my emphasis):

In the end I chose eXist because it is open source, it stores my data as xml, outputs it as xml etc. Also I had also had some experience with xquery in my previous position and I liked the idea of being able to run the whole web application using only xquery, xpath and XSL, all of which I was at least familiar with.

Internet-facing desktop applications

2006-09-09T14:58:00.000Z

A really interesting discussion is underway about Webified Desktop Apps vs Browser-based Apps over on Read/WriteWeb.

The general point is that whilst web-based applications are incredibly useful:

the future of computing isn't entirely web-based.

Author Ebrahim Ezzy argues that instead, the desktop must be improved:

What we require then are smart, webified, internet deployable desktop applications - that can reliably store data, serve it robustly, and interact with both remote and local databases. This connected model will ensure that applications will function in both online and offline states - for a seamless, uninterrupted experience.

The fact that this topic is getting discussed is great, although I think from the comments and views that I've read, one permutation is missing, and that is the creation of an additional layer above the desktop that web applications can make use of to turn themselves into desktop applications. A key part of this idea is that this layer should be standard.

That's what we've done with Sidewinder; we've created a cross-platform environment that supports features such as creating windows that dock to the side of the display, can auto-hide, have transparency and opacity, and so on. Sidewinder also allows events that are fired in one window to be registered for in another (allowing applications to be built from smaller pieces).

However, unlike traditional desktop applications that need to be written in C++ or Java, Sidewinder applications are written in either XHTML or JavaScript...or more often than not, both.

So a web application could be as simple as an XHTML file that contains a page with a clock in it, through to a complex application in JavaScript, that in turn creates many XHTML windows and manages events passing between them.

We call these applications 'internet-facing desktop applications', since they want to be desktop applications, but they have so many internet-related features that they are most easily built using web technologies such as HTTP servers and XHTML pages. By providing a framework that takes this into account we can get the best of both worlds.

I mentioned that a key idea was the use of standards, and Sidewinder uses XHTML, XForms, SVG and MathML to build applications.

We have various demos that show how easy it is to make a web application into a desktop one:

KoolIM as a desktop chat application;

Technorati Mini as a desktop application;

Enhancing your Google Calendars.

Ajax makes browser choice irrelevant...but we still need standards

2006-09-06T16:58:00.000Z

A discussion is running in various places (such as on the W3C's XForms list) about whether to add lots of new features to developers' armoury (XForms) or just a few (Web Forms 2.0).

The former (XForms) attempts to capture a wide range of patterns that recur in web applications, such as retrieving data without replacing the document the user is viewing (yes...XForms defined that a long time ago!), client-side validation (that too), using mark-up to provide tooltips and help, rather than using script (yes...), having controls such as calendar widgets and sliders built into the language (no-one told you?) and more.

The latter (WF2) claims to add a few small improvements to HTML forms, so as not to move too far from current practice. This might be commendable in itself, but the truth is that as the WF2 specification has evolved, it has increasingly added features that make it about as similar to HTML forms as...well, XForms is. There are new attributes and elements, new interfaces, repeating constructs, new submission protocols, and so on. In fact, the truth is that the major differences between XForms and WF2 are not in terms of simplicity (XForms can do 'simple' in a way that is actually more intuitive than HTML forms) but that XForms supports an MVC architecture, and allows you to submit data without replacing the current page. It's unlikely that in 2006 anyone would want to be without either of these.

Who is using HTML forms anyway?

But the real irony with WF2 is that even if the spec had limited itself to 'small changes' instead of the large number it has added, 'current practice' is actually not to use HTML forms anyway! 'Current practice' either involves using some kind of server-side processing that hides HTML forms from you--such as Struts or Ruby on Rails--or it involves hand-coding Ajax yourself, using one of the many high quality libraries that are available.

Browser-choice is increasingly irrelevant

What I find most interesting though, is the mistaken belief amongst proponents of WF2 that anyone really cares what browser manufacturers do. Unfortunately the W3C suffers from the same delusion; they recently decided that one form-related standard wasn't enough and that there wasn't quite enough confusion in world of the web, so they invited the WHAT WG to bring their quaint ideas into the fold. (One of these quaint ideas is that XML won't catch on, which would be mildly amusing if such Luddism weren't now being courted by the W3C.)

Why do I say that browsers are increasingly irrelevant? Well, imagine that the Ajax libraries just keep getting better and better, and increasingly 'hide' the differences between browsers. I think that's a pretty safe bet, since the leading libraries show no signs of slowing down their development and innovation any time soon. With such a context we actually get an increase in conformance, not a decrease, and authors are able to write for all browsers rather than the "dominant" one. At a certain point, which browser your customers use becomes increasingly irrelevant.

Whereas in the past it was up to all of us to test our sites and applications in the various browsers available, now we can leave that to the Ajax library authors, which has got to be a far more efficient use of everyones time.

The browser war is therefore over, not because any one browser has won, but because developers could care less about the browser as a browser--instead one or other Ajax library becomes 'the platform'. In parallel, users will tend to use the browser already installed on their computer, or the one that is mandated by their employer--likewise making the actual choice of browser irrelevant.

Extended browsers

Actually, to be more precise, what will increasingly happen on the user side is that we will choose our browser on the basis of handy features like tabs, or task-related features like RSS readers, photo sharing, blogging tools, and so on. Whether Flock and Songbird get it right remains to be seen, but there is no doubt that people will use products such as these if they serve their purpose. And that's a far better basis on which to choose a browser than which version of CSS it supports.

Standard Ajax

Then at some point the cry will go up: "Why do there have to be so many Ajax libraries? Can't we standardise on these browser enhancements? Has anyone written a tool for porting my YUI x.y application to Dojo a.b?"

That, at least, will be the cry coming from developers, if it's not already; the end-user on the other hand will now be dealing with a different set of problems, and their cry will be "Why doesn't the new browser I've just installed work with my Flickr photos, my Blogger blogs, all my dates in GCal, and all my favourites stored in del.icio.us, like my old browser did?" I guess that's progress...

XForms, SMIL and the W3C

At least for developers there's some good news though, in that the XForms WG have been working for years on exactly the kind of standardisation that is needed to sort out 'the platform'. In fact, the W3C has lots of excellent work it should be making more of, such as:

SMIL: which covers a large part of most Ajax libraries, animation;

DOM 2 Events: easily supported in script, and provides a standard eventing architecture rather than the growing number of library-specific models that are emerging;

and so on.

The W3C therefore has an important role to play in the future of web application standards, but by using its experience in defining 'the platform' not being bounced into worrying about the future of the browser. It will only be able to help define the emerging platform if it takes seriously its tagline of "Leading the web to its full potential...", and does some leading!

Time for a widget spring clean

2006-09-01T14:48:00.000Z

Every now and then, when I'm looking for something else, I stumble across a widget or an application that we've built using Sidewinder and formsPlayer, but for one reason or another we didn't get round to putting on the site. (Good old Google Desktop Search!)

Actually, there is only the one reason they haven't been added and that is that we've been incredibly busy, but over the next period we're going to make a concerted effort to get some of these goodies out, so that people can start playing with them.

We'll be adding them to the Sidewinder handbook, along with descriptions and tutorials.

Creative Commons' Firefox plug-in now supports RDFa

2006-09-01T13:32:00.000Z

A recent announcement on the CC site says that MozCC 2.2 now supports RDFa.

Editing XForms documents with the xH schemas

2006-08-31T16:46:00.000Z

The schemas used to validate XHTML documents in Sidewinder are now available for separate download. This is particularly useful if you use an XML editor to create XHTML + XForms documents, since many XML editors can use schemas to guide the editing process. (Instructions are available, showing how to configure oXygen.)

The current collection of schemas uses XHTML 1.1 Modularisation techniques to incorporate XForms, SVG and MathML into XHTML, and we've called the complete combination xH.

Sidewinder and GCal desktop applications

2006-08-23T22:56:00.000Z

The latest release of Sidewinder sports some interesting features which should go a long way to enabling desktop applications to be built with HTML and Ajax. For example, it is now possible to dock any number of windows to the same edge of the screen, and have them auto-hide independently. (Previously you could only have one window per edge.)

It's also possible to intercept requests for new browser windows that are made by Ajax applications running in Sidewinder. The JavaScript application that invoked the Ajax application (it's actually pretty simple!) then gets the chance to create any type of window it wants--transparent, docked, autohiding, etc.--before returning it to the Ajax application.

Phil Booth has written a couple of blog entries that illustrate the new features, and has included sample code. The first explains how to create multiple docking windows at postions that are calculated at run-time, and it builds on the JS application for Kool IM. The second, and most recent, shows how multiple GCal windows can be created, giving a great deal of flexibility (and control) over how you organise your desktop.

Using the role attribute to extend XHTML

2006-08-21T10:07:00.000Z

An interesting suggestion came up recently on the www-html mailing-list. Ahmed Saad suggested that an attribute could be added to HTML which when placed on an element would tell the browser not to execute any script contained within. This could be used to wrap comments added to a blog, and so prevent executable code from being uploaded. Ahmed gave an example of his proposal in action:

<div id="comment123" nocode="true">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

It's certainly a great suggestion, but it's also the kind of thing that is just so easy to do with the proposed role attribute, that I thought I'd use it to illustrate how some of the new hooks being added to XHTML allow to be easily extended in a decentralised way, giving different interest groups the ability to bend XHTML to their own purposes.

The `role` attribute

The role attribute is a new feature in XHTML 2 that is being made available via a module so that it can be used in XHTML 1.x. (You might also be interested in The XHTML role attribute: small and perfectly formed, and XHTML 2 and the Semantic Web: Are we nearly there yet?)

Adding functionality

We generally need two things to implement an idea like Ahmed's in XHTML:

some agreed mark-up to allow the author to signal that they want to make use of the feature;

a description of exactly what the behaviour should be.

Traditionally both of these parts of the requirement would have come from members of the HTML Working Group, after much discussion at meetings and conferences, on phone calls and of course with other interested parties, on mailing-lists. But there is no reason for this to be the only way to grow the language, particularly when it comes to 'light-weight' features such as the one being proposed here.

To illustrate, I'll show one way that Ahmed's requirement might be implemented, using the new hooks.

The mark-up

To flag up the use of the feature in the mark-up, we could simply use an agreed value in the role attribute, with Ahmed's nocode="true" suggestion becoming role="nocode":

<div id="comment123" role="nocode">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Even better, we could actually define this block as what it really is--a comment--and let the fact that code should not be executed be a consequence of the block being a comment, rather than some 'floating' property:

<div id="comment123" role="comment">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Globally unique

One of the key ideas of the role proposal is that is makes use of QNames to allow for the clear identification of concepts. There may be some systems in which a comment should contain executable code, for example--in other words, your comments may not be the same as mine. For the sake of our illustration, let's pretend that part of the Atom suite of specifications is a set of terms that can be used in situations such as this, and it includes the definition of atom:comment:

<div id="comment123" role="atom:comment">
  <script type="text/javascript">
    alert('This piece of code will not be executed even ¿
    though it evaded the server-side filter');
  </script>
</div>

Now we have a way of uniquely identifying 'Atom comments' in any XHTML mark-up, without having to extend XHTML (beyond the addition of the @role attribute, that is).

Defining features

Now that we've created a way for an author to tag different parts of their documents, we also need to define what these tags mean. This is usually done in the HTML specifications themselves, but the role attribute gives us a decentralised way to add functionality to XHTML.

The easiest way to define the functionality is in prose. We might say that 'an Atom comment is any text added to an entry, and any mark-up contained in the comment is to be rendered as if it was in a CDATA section'. Or we might say 'any script elements can be ignored'. The actual definition is not important here, the key point is simply that somewhere there would be definition of an atom:comment.

The role specification goes further than allowing simple text definitions for objects, and allows the use of RDF to give more precise, machine-processable instructions. We won't go into the mechanism here, but a trail is already being blazed in this space (with a particular focus on accessibility), by Lisa Seeman and Richard Schwerdfeger; look at their Role Taxonomy for Accessible Adaptable Applications. In particular, they have a great example that shows role being used to indicate that a span is actually serving the purpose of a tri-state check-box.

Conclusion

None of this is to say that we need never extend HTML again, but there are certainly an enormous number of features that could be easily added via the new extensibility hooks added to XHTML--something that vertical markets and distinct interest groups will find useful.

Making a desktop chat client from Sidewinder and KoolIM

2006-08-08T01:31:00.000Z

KoolIM is a very impressive web application that allows you to chat with people via any of the popular messaging protocols. The KoolIM servers do all the work of translating the protocols, which means that the user interface need only communicate over HTTP to the KoolIM servers. It's therefore possible to build chat clients with HTML, which of course means that users do not need to install any special software and can chat with friends and colleagues from almost anywhere.

Since KoolIM supports so many protocols it's an extremely strong candidate to be used as your main chat software, following the trend set by Google web applications for email, diary and spreadsheets. Although the applications themselves are incredibly powerful, you still feel like you are running a web page in a browser--and that's the problem that Sidewinder aims to solve.

Sidewinder is a framework which makes web applications look like desktop applications, by providing features such as docking to the side of the display, auto-hiding, opacity, transparency, and so on.

The latest release of Sidewinder sports an extremely useful feature which is an event that tells an application when a new window is being created, and then allows a renderer object to be provided instead of the usual browser window.

Since the KoolIM web application creates new windows whenever a new conversation is started, then substituting a renderer window allows us to make the already professional looking KoolIM feel that bit more slick; with a few lines of code it's possible to provide KoolIM with a window that docks to the left side of the screen and automatically hides when the mouse is moved away, or to alter the position of successive windows so that they are all visible, or even to create a semi-transparent window that will always be visible in a corner of your desktop.

We've provided full details in a skimstone article, along with details on creating a desktop calendar with Google Calendar. If you want to give these applications a try you'll need the latest release of the Sidewinder beta, and it would be worth reading the notes on writing applications with JavaScript.

Application development with XML objects

2006-08-05T14:10:00.000Z

An XML language that allows for the definition of objects with methods, properties, and event handlers is a key component of the web application architecture that we are trying to build. The general idea is that an XML DOM node can be treated as a kind of base class, and some declarative language is then used to specify additional features to add to that class. By allowing more than one of these XML objects to be bound at a time to a DOM node, we overcome the problems and limitations that arise from multiple inheritance in OO languages like C++.

But most significantly, by allowing the selection of these objects to be determined dynamically, at run-time, as the DOM itself is changing, we create a powerful and effective application-building environment; it's as if our application is recompiling itself into new shapes as it runs.

To fully make use of such a technology we need two components, one to describe the XML objects themselves, and the second to indicate when to use them--i.e., which XML objects to 'attach' to which DOM nodes, and when.

I'll look at the selection language in a separate post; in this one I'd like to look at how we might actually specify the XML objects themselves.

XBL as an object definition language

XBL is a pretty good candidate for being the 'XML object definition language' part of the equation. It's been around for a while, and has been used in Mozilla browsers for a number of years. Attempts are underway to update and formalise the language under the banner of the W3C, although whether this will happen or not is unfortunately less about the appropriateness of the specification, and more about the personalities involved.

Having said that, it's not completely obvious that XBL is the right tool for the job anyway. Although the advantages of XBL are in its maturity--it has been implemented for a number of years in Mozilla-based browsers, and we have also implemented an XBL processor for IE as part of formsPlayer--the disadvantages are that it requires a new language, and this language is tightly integrated with CSS. Given that we already have a language for defining 'web objects' with which far more people are familiar than XBL--XHTML--it's worth considering whether is is more efficient to use that.

XHTML documents as objects

Making use of XHTML itself requires only a very small leap in our mindsets, since XHTML already defines web applications as a combination of script and mark-up. All we would need to do to make use of XHTML as an XML object definition language would be to specify the process by which an XHTML document is in turn used as a component within another XHTML web application.

As it happens, we can do a little better than that, and make it easier to specify script-related functionality in mark-up. This would be of some benefit anyway in our normal documents, regardless of whether those documents are embedded in others.

(There is of course a precedent for this, and that is HTC from Microsoft, and its successor Behavioral Extensions to CSS. This language never really took off, most probably because it smacked too much of being Microsoft-only, although Mozilla producing something separate wouldn't have helped. Either way, some might argue that XAML is Microsoft's updated solution to the same problem.)

Properties and methods

To give an example of how this might work, take a script in which we declare a variable that can be used by other scripts in the same web application:

<script type="text/javascript">
  var gInitialised = false;
</script>

This could easily be expressed as something like:

<property name="gInitialised" initial="false" />

Similarly, we often declare functions in the following style:

<script type="text/javascript">
  function animate(el, attr, from, to, dur)
  {
  }
</script>

This could be expressed as follows:

<method name="animate">
  <parameter name="el" />
  <parameter name="attr" />
  <parameter name="from" />
  <parameter name="to" />
  <parameter name="dur" />
  <implementation type="application/x-javascript">
    ...
  </implementation>
  <implementation type="application/x-python">
    ...
  </implementation>
</method>

This is by no means a concrete proposal, but even from this 'mock-up mark-up' you can see that there are many advantages to be had over using the normal 'inline script' approach. The most obvious is that we can easily locate the methods we are using in our applications, making them available to other tools. But note also how we have provided different implementations for the method, allowing the client application to choose from them based on what languages they support. This is an idea proposed by Steven Pemberton in his XML Handlers draft (at the moment only available to W3C members) but seems to fit nicely with the general definition of methods.

Conclusion

As I say, I'm just playing with the syntax here, but the key point is that since XHTML already defines complex objects using XML, then why not use it define objects that can be used recursively? By adding an XHTML 1.1 Modularisation module we could easily obtain the ability to define methods and properties in top level XHTML documents, and the same technique is obviously usable for bound objects.

And one final bonus from using XHTML to recursively extend itself is that we immediately have at our disposal an enormous resource of readily available objects and components...the current web.

(I've written on our skimstone site about using XHTML as a programming language, as well as an older blog about XHTML as a base for web languages.)

Using subforms in XForms

2006-08-01T22:10:00.000Z

Over they years I've had cause to write many different kinds of form-based applications. At one time I had to write them in C++ or Java, but that was a long time ago! For simple applications that had to be produced quickly (and could change a lot) I had to use VB or Microsoft Access. But like most people nowadays, most of the recent decade has been spent using one kind of server-based application after another to produce HTML user interfaces.

But no matter which language was used, the same problem always presented itself; how do we make big forms out of small forms?

We've been working on this a lot lately, because some of the forms in a current project are very big. Of course, they could be made smaller, and we could get our users to move from one form to another as they perform their tasks. But doing this would require us to pass state information between forms, either in cookies on the client, or via the server, and the latter approach binds us in far too tightly to the server software. (See skimming.)

The ideal technique is of course to only load parts of the form as they are needed. But this is not as easy as it sounds, and keeping track of this at design and build time, especially in a scripted environment, is next to impossible.

In all the years I've been building applications, I've never managed to find a decent solution, but I feel that XForms may finally provide a reasonable way.

Extending the `load` action

The technique we used on the current project is to extend the XForms load action to include:

a target attribute to indicate where to place the sub-form;
an additional value in the show attribute of embed.

To show how it works, here is an example of how we place a sub-form into a case when the user toggles that case:

<xf:load
 target="div-work-list-choose"
 ev:observer="case-work-list-choose" ev:event="xforms-select"
 show="embed" resource="subforms/sf-work-list.xml"
/>

We use the term sub-form to describe the document that is loaded because it may have more than just controls; it may include its own models, submissions, bind statements, and so on.

Using XLink

The extensions to load are of course non-standard, and this is still very experimental. But it is worth saying that there is logic behind the way we've done this. For a start, XForms really should support a target attribute on the load action anyway, which would allow new documents to be loaded into frames or other locations.

But also, the show attribute in XForms is actually modelled on the XLink show attribute, and the currently supported values--replace and new--come from that...as does embed. In other words, all we're suggesting here is that XForms supports a little bit more of XLink.

As it happens, our first version of this functionality achieved it using raw XLink, but the problem is that XLink says nothing about when to load the sub-form. Once we started looking at attaching event listeners, we quickly came to the conclusion that load was much more appropriate, particularly because it already made use of XLink.

Conclusion

However we do this in the future, and whatever mark-up is used, XForms definitely provides the hooks for a flexible way to build complex forms on the fly. Defining the loading of sub-forms using declarative mark-up makes it intuitive for authors to use this feature, and makes the management of the components much easier.

Why Microsoft might not embrace XHTML (and then again they might)

2006-07-28T15:46:00.000Z

As usual I've had my thoughts provoked by Kurt Cagle. I missed the post originally, but T. V. Raman pointed out to me that a month or so ago Kurt wrote about why Microsoft should embrace XHTML. Actually, the post is entitled Why XHTML Can Save Internet Explorer, but since I'm not really sure what IE is being saved from, I'm sticking to Kurt's main point which is that IE developers have an opportunity to move their browser on, but only if they embrace XHTML.

I think there is a lot of merit in Kurt's argument, but it might not be as clear cut as he presents; I certainly think that if the W3C was to get its act together and turn its collection of disparate languages into a coherent whole, then XHTML could be a serious challenger to XAML, and that might make it less attractive for Microsoft to support.

Of course, it might make it more attractive to support, too. Standards are a double-edged sword for the big guys like Microsoft, since they would all ideally like us to only use their proprietary formats, but they generally realise that this isn't the way of the new internet. It's interesting that we haven't heard much about XAML in the recent period, which either means that MS are taking advantage of the 'current obsession with Ajax' to quietly get XAML ready, or they realise that the 'current obsession with Ajax' means that people actually like standards.

MIME types

The core of Kurt's argument is that since a new MIME type is used for XHTML documents (application/xhtml+xml) then Microsoft can shift to this mark-up language without the usual fear of 'legacy' problems.

Kurt's argument is exactly right, and it's the basic reason for the separate MIME type in the first place. It's also worth stressing that this is also the reason why people such as Ian Hixie have for a long time urged a clean separation between HTML and XHTML, and discouraged people from using incorrect MIME types.

Sidewinder

The 'separate paths' approach is interesting to me also, since it is what has allowed us to support the application/xhtml+xml MIME type in Sidewinder, our rich web application client.

With Sidewinder installed, Internet Explorer will advertise to web servers that it supports XHTML documents. Should a server actually send one, then Sidewinder will be invoked to do the work of processing it, and will run embedded in the browser. In this it is no different to how you might interact with a PDF file, for example, but we generally don't tend to think of documents from the HTML family as being as distinct as a Word document or an Excel spreadsheet; having separate MIME types for the different branches of HTML allows us to treat them in this way.

Although Sidewinder runs within IE, it manages its own communications (via the impressive libCURL open source library), and this makes Sidewinder independent of the browser framework, which in turn means we can do all sorts of things with the document during processing.

XHTML Compound Document Validation

For example, Sidewinder validates the XHTML document being loaded; we use schemas created using the principles in XHTML 1.1 Modularisation, with extension modules that provide support for XForms, RDFa and SVG. (The skimstone site has more information about the schemas used in Sidewinder.)

XHTML Compound Document Rendering

As well as validating compound documents, Sidewinder can render them; if you have installed one or more of:

the Adobe SVG Viewer;

our own formsPlayer;

Design Science's MathPlayer

then compound documents that include SVG, XForms and MathML will be completely rendered.

XHTML as a web application language

One of the reasons we've developed Sidewinder in the way that we have is that we believe that building internet-facing applications is made much easier by using internet-related languages.

It would be unusual today for a desktop application to be independent of the internet; even an accounts package will use the web to save data, retrieve news items about your industry, and automatically obtain upgrades. But it doesn't just 'connect' to the internet; most modern applications use an embedded web browser at some point to render reports and forms, making the connection between an application and web-focused technologies extremely tight.

The growth in the list of impressive web applications that cover email, spreadsheets, online chat, and so on, demonstrates that even with the current limitations of HTML, it can still be cajolled into making software people want to use. But everything we're working on--from software like Sidewinder, to our involvement in standards organisations--is about saying "why stop here"; why not make XHTML even better for building internet applications?

Advancing XHTML

In our view, if the mark-up is powerful enough, at a certain point it becomes a lot easier to build these kinds of applications using XHTML and XForms than it is to create them with C++ or Java. This is partly because the languages are internet-oriented, but also due to their declarative nature.

Sidewinder is a framework that makes this even easier; it provides a desktop environment in which to run XHTML and JavaScript applications, with dockable windows, autohiding, transparency, and so on. (It's even possible to run applications that are Javascript-only.) Sidewinder provides a rich container for web applications, but we're actively pushing standard mark-up languages as far as we can, to make them deliver the kind of functionality that is needed.

(Some other features of our approach are discussed in Web 2.0, Copernicus and Spartacus: Moving the centre of the web.)

XHTML v. XAML

So to return to Kurt's point, given what XHTML could be, it's certainly possible that Microsoft won't want to support it at all. It's certainly possible that all of the things that Kurt is talking about--and indeed those that I am talking about, too--will be implemented, but only in order to support XAML. XAML will be the language of choice for Microsoft, and they will push it for use as both a web application language, and a desktop application language.

But then the last year or so has been quite a surprise for everyone, and one of the key messages is the groundswell of support for open standards and consistent browsers. In today's climate it would take an incredible marketing effort to 'sell' XAML as the 'new language' of the web, and you do wonder what exactly it would gain them anyway.

Of course it wouldn't be the first time, but Kurt might just be right. And if he is, then XHTML could really take off.

XHTML 2 and the Semantic Web: Are we nearly there yet?

2006-07-26T20:49:00.000Z

For me one of the more interesting aspects of the new wave of web applications is the way that developers are increasingly seeing the benefits of taking a more 'semantic approach'. By this I mean that instead of creating a menu (for example) from a JavaScript library or a collection of div elements, authors are more and more using the HTML element that comes closest to what they want, and then using CSS or attached behaviours to achieve the functionality they desire. (In the case of a menu that might be li.)

This has many advantages, from improved accessibility, through to easier code development, maintenance and re-use.

I mention this because an important step along this path is provided by XHTML 2, the next generation of the W3C's XHTML mark-up language, and a new working draft has just been made available.

XHTML 2 takes the ubiquitous mark-up language back to its HTML roots, being both cleaner and more semantic than previous versions. In particular, the incorporation of RDFa and the role attribute position XHTML 2 to provide the 'missing link' to the creation of the semantic web.

(The role attribute allows systems to understand the purpose of some mark-up, and so make decisions about providing alternative means to achieve the same end, whilst RDFa is "microformats done right", as Bob DuCharme said, and makes it possible to add powerful metadata from any vocabulary, without having to wait for a committee to approve your tags.)

No doubt this will trigger the usual questions of "will IE10.5/Opera 12/Firefox 3 support XHTML 2?", and of course, the answer is "who knows"! But I would urge anyone involved in building web applications to take a look, since it's the approach that is most exciting, and it may just give you some ideas to use in your own work.

The web is changing...

The XHTML role attribute: small and perfectly formed

2006-07-25T20:54:00.000Z

What, more publications! Indeed it's true.

The W3C have released the XHTML Role Attribute Module. It originated as an idea from T. V. Raman and Steven Pemberton, was then folded into XHTML 2 (although not before I'd managed to sneak a healthy dose of RDF into it), and has now come back out of XHTML 2 as a standalone module. (RDF intact, you'll be pleased to hear.)

The idea is that it can be used in languages based on XHTML Modularisation, to provide information about the purpose of some part of a web page. (The problem with using @class is that you can't be sure whether the author really means what they say. It's not the author's fault...it's just that @class has been used for many things over the years.)

@role has already been well received by both the accessibility community and mobile operators producing content for small devices. Indeed Firefox is already implementing and supporting the attribute.

And it has to be said that it's an ideal spec...one attribute, a few values, a little bit of prose, and then convey the entire idea in one example:


<ul role="navigation wai:sitemap">
    <li href="downloads">Downloads</li>
    <li href="docs">Documentation</li>
    <li href="news">News</li>
</ul>

In fact, the spec is so compact that the list of editors is the longest part. :)

But as you can see, you really don't need much more than this one example to immediately see that role can be used for many purposes; from creating accessible content, to triggering server-side transformations of content prior to multi-device delivery.

I'm looking forward to seeing other uses of this simple idea, and complementary work to produce a taxonomy for accessible components is already well advanced, thanks to Lisa Seeman and Richard Schwerdfeger's efforts.

Postscript: If you work in the area of accessibility, then you are probably already aware that Raman has had far too much press coverage this week. I won't draw attention to it, since it will only encourage him. Instead, here is a link to a picture of his talented dog Hubble, flying an aeroplane. More pictures are here.

Rich Web Application Backplane

2006-07-20T11:32:00.000Z

I was pleased to see the publication yesterday of a note from the W3C entitled Rich Web Application Backplane. I was involved with the production of this document, writing one of the sections, but the strength of the note comes from the way that Charlie Wiecha has pulled all of the pieces together. It's an early draft, and there is plenty more work to be done, but I think it's a good start.

The document argues that standardising interfaces and finding common components--what software developers might call factoring--will benefit everyone, particularly if applied to W3C standards. All contributors to the document are people who have pursued, written or spoken about this kind of work, and it's great to see some 'cross-discipline' effort going on.

Other contributors are:

John Boyer, co-chair of the W3C XForms Working Group;

Steven Pemberton, co-chair of the W3C XForms Working Group, and chair of the W3C HTML Working Group;

Kevin Kelly, chair of the W3C Compound Document Working Group;

and Al Gilman, chair of the W3C Protocols and Formats Working Group.

Declarative Ajax...Now we're talking!

2006-07-19T01:46:00.000Z

We've been so busy here in the office working on an exciting project for a customer that I haven't had a moment to raise my head above the parapet. I'm desperately trying to find some time to write about how easy it is to use XForms to drive OpenWFE and eXist. That's three technologies in one place that I'm besotted by, but it looks like it may have to wait just a little longer before I can write about it.

(Uncannily, I've just been asked to give a presentation on real-life uses of XML access languages, at a joint meeting of XML UK and the W3C Office for UK and Ireland, so I'm going to talk on "XForms and XQuery, via REST". I'll try to put some slides and sample code up in advance of that.)

Anyway...the point is that it just shows how busy we are that I completely missed a great post from Duncan Cragg entitled The Right Way to do Ajax is Declaratively! What more can I say? Duncan's own views are, as always, very interesting, and what's more it contains a large number of links that are jumping-off points to lots of other articles and presentations on the subject.

I think it's well worth a look if you haven't already seen it, and is a useful summary of some of the ideas and software that are becoming important.

XForms and Internet Applications

Linked Data and RDFa in US and UK government web-sites

Understanding the XForms dependency engine

RDFa Tech Talk, at Google, 2009

XForms Developer Zone and User Group launched

Tokenising the semantic web

More RDFa goodness from UK government web-sites

RDFj: Semantic objects in JSON

Update to 'Getting started with RDFa: Creating a basic FOAF profile'

Customising initial instance data in an xform

Duck-typing and XForms

Compact HTML: A mark-up language for micro-blogging

Compact HTML

Why HTML?

Other tokens

An example

Microformats and RDFa are not as far apart as people think

Openness and Innovation Presentation at Media Futures 2008

@role values for SVG

SVG

Upcoming talks on RDF, RDFa and XForms

So how about using RDFa in Microformats?

Emphasise the 'micro'

rel-license

Reusing @src attribute

RDFa or Microformats?

First steps in RDFa: Creating a FOAF profile

FOAF

Creating a person

Adding personal information

Creating a profile

Adding friends and colleagues

Adding a picture

Linking to a Twitter account

Human and machine-readable

The whole shebang

Publishing your FOAF page

My Profile

RDFa is now in last call

Google's Social Graph API, RDFa and the future of web search

Creating desktop applications with Popfly and the Sidewinder Viewer

Welcome to Planet XForms

Yahoo! uses XForms for 'write once, run anywhere' mobile applications

skimming at XML 2007 (and The Cloud's Silver Lining)

GData

SimpleDB

RDFa, @profile, and following your nose

@profile

RDFa is unambiguous

Indicating the presence of metadata

Confusion

Conclusion

Embedding OWL-RDFS syntax in XHTML with RDFa

Once more on information resources and RDFa

Illustration

Intelligent links

Conclusion

Using URLs to pass parameters to web applications, widgets and gadgets

meta and link values

Google Reader

Command-line parameters

User control

Next steps

Further reading

Sidewinder is open source and gets a new home

Getting started with Sidewinder

Converting HTML to RDF

One step closer to bridging the clickable and semantic webs

Sidewinder and the need for a semantic web applications framework

For every problem...

Fixing the web, Part 1

Ajax and progressive browser enhancement

DOM Events and standards

Using JavaScript to enhance the browser

Threading in Google Gears

Yowl centralised notification system

Where does this leave the browser?

RDFa used in Joost

Of pots and kettles (more squabbling between Sun and Microsoft about standards)

Yowl: Design principles and how to use it

`meta` and `link` values