Monday, May 23, 2005

XForms tutorial part 2

THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...





As long as I can keep up with it, I'm trying to track people who are linking to this weblog and saying thanks! Molly E. Holzschlag added the tutorial to her list of links. Her bio says "Molly E. Holzschlag has authored over 30 books related to Web design and development. She's been coined "one of the greatest digerati" and deemed one of the Top 25 Most Influential Women on the Web." Wow! And thanks for mentioning me.


XForms can be overwhelming. Let's start hello-world-style. First of all, you need an XForms engine. I prefer the Mozilla implementation, but it isn't finished yet. I fail to get some essential features to work. These should be fixed if I would download the latest source code and compile it myself. But in the latest beta, it doesn't work yet. Nevertheless, I'll start with Mozilla, and when I need it, I'll introduce an alternative implentation. I think it's interesting anyway to investigate to which extent XForms are portable and compatible for different viewers.


Getting XForms for Mozilla

XForms for Mozilla is an XPI plugin and is not preinstalled together with the browser. In the current plans, this will not change for the initial releases. The XForms beta does not work with current releases of Firefox (up to 1.0.3). You need to download the 1.0+ version separately before you can install the plugin. This is 20050523, for the most recent information and downloads, visit the Mozilla XForms project page.

It took some time before it was decided that XForms was implemented on the Mozilla platform. The reason for this resistance is interesting enough to mention here. There is a relation between whether you like XForms or not and whether you are an application developer or a pure web developer. Web developers like to keep things easy, user friendly and error forgiving. They prefer HTML over XHTML and are more interested in its layout capabilities than its semantic capabilities. Application developers prefer more sophisticated modeling tools that fail fast on errors and force developers into adhering to strict standards. Web developers think this makes it all more complicated than necessary.

XForms is an extensive modeling tool with many features more interesting to application developers than to web site designers. The decision to implement XForms on the Mozilla platform was pushed (not to say "forced") by several large companies (Novell, IBM). While some are arguing that Firefox should be a web browser and nothing but a web browser, these large companies have enough interest in Mozilla as an application platform to invest in its development.

I consider myself an application developer who develops web applications by coincidence. This explains a little my interest in XForms. How complicated XForms are (or not), is something this tutorial should point out.

Enough with the background information.


A very basic XForm


<?xml version="1.0" encoding="iso-8859-1"?>
<html:html xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events">
    <html:head>
      <xf:model>
        <xf:instance id="resume">
          <resume xmlns="">
            <firstname>Adriaan</firstname>
            <lastname>de J.</lastname>
          </resume>
        </xf:instance>
      </xf:model>
    </html:head>
    <html:body>
      <html:p>
        Resume for
        <xf:output ref="instance('resume')/firstname" />
        <xf:output ref="instance('resume')/lastname" />
      </html:p>
      <html:p>
        First name: <xf:input ref="instance('resume')/firstname" />
        <html:br />
        Last name: <xf:input ref="instance('resume')/lastname" />
      </html:p>
    </html:body>
</html:html>


If you have the right version of Mozilla and the plugin, you can view the example here.

This example is extremely basic. It does almost nothing. The only interesting thing you see here, is that when you change a value in one of the text boxes and tab to the next field, the information in the output fields automatically changes. Probably you think this is not earth shocking, but please note there is NO scripting in this example, and there aren't even XML triggers or events defined. This works out of the box; a standard declarative feature.

I'll leave it at this for a hello world.


What else do you notice?

I see an event namespace being declared but not being used. I could have deleted it for this example. It will be used later on in the tutorial.

I see separate namespaces for XHTML and XForms. They mix with each other. This indicates that XForms is very modular. It is possible to build an XForm without XHTML. For instance, you could also mix it with SVG. With a little fantasy, you could design eye-candy graphical interfaces mixing with data source documents in a very dynamic interactive way.

I see instance data mixed in the document. In practice, most likely this mixing is evil. In the next example you'll see the instance data replaced by a reference to an external file.


That's pretty much it for this simplistic example. From here we can introduce features to build the full curriculum vitae document. Stay tuned!


THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...


5 comments: Links to this post

Sunday, May 22, 2005

XForms part 1.5

THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...




To my surprise it turns out people are reading my weblog. I didn't know Technorati until now, I didn't plan to add the weblog in Google until at least some articles were finished. I didn't know it was so easy to find weblog posts and exposure is this big. In addition, Anne van Kesteren already added a link to part 1 while the article doesn't contain a single line of actual XForms code. Dank je wel, trouwens!

This keeps me awake: I need to hurry to write part 2. In the mean time, these are a few additions to part 1, still without a single line of XForms code. But stay tuned!

A short recap

In the XForms tutorial I am exploring techniques for building graphical user interfaces specifically targeted at editing XML documents. Instead of working with general UI elements and writing loads of custom code translating to XML, I would like a declarative syntax that translates to a dynamic form document.

As a working example, I am using a curriculum vitae. Usually job agencies work with client side programs with hard to understand user interfaces for inputting data and need to do a lot of manual work to export the data to Word documents. Instead of the separation between user input and document export, I would like a user experience that can be summarized as:

The user interface form IS the curriculum vitae document and the document IS the interface.

The user shouldn't see differences between editing a CV in Word and editing in the XML user interface. However, the interface handling should translate user input to a semi-structured XML document instead of an unstructured Word document. To accomplish this, we need software following a model similar to:



A few additions

In part 1, I forgot to say a few things. Most importantly: XForms is NOT the holy grail. When you are developing XML document solutions, you should consider the alternatives. In part 1 I have mentioned a few. But I forgot an important one. My employer would not be very glad if I didn't mention it.

The Adobe XML Forms Architecture (XFA). Probably you have seen a form in a PDF document. Most likely this is NOT XFA. Acrobat has forms comparable to classic HTML forms. These are good looking, usable, but do not follow the architecture in the picture above this text. Adobe also offers a solution using Adobe Designer for creating forms and Adobe Forms Server for handling form data.

Main advantages:
  • The forms are VERY good looking; they look exactly the same as their paper hardcopy alternatives.
  • The forms architecture handles common problems like security, public key infrastructures, etc.
  • The forms are available in Acrobat Reader which is widely deployed on many computer networks.
Main disadvantages:
  • The software is very expensive.
  • The software contains a lot of bugs and need a lot of JavaScript hacking to solve real world problems.
  • Error messages in JavaScript are very poor; which makes debugging hard and time consuming.
  • The forms are as static as the paper counterparts.
  • JavaScripts for Acrobat Reader versions 6 and 7 are not 100% compatible.
However, for government organizations making their paper forms available in electronic format, this is a popular solution.


Don't underestimate InfoPath

In part 1, I did not give enough credits to Microsoft InfoPath. In my "the document IS the interface"-philosophy, InfoPath might be the best solution available. It looks very similar to a Word document and is a relatively mature and stable solution to the issues I'm trying to solve. Also, since InfoPath service pack 1, Microsoft offers integration with compiled .Net code. You can replace the JavaScript backend by a compiled .Net backend. This makes the possibilities practically unlimited. The resulting interface is very user friendly. The only thing I miss, is the option to integrate an InfoPath form as an ActiveX control into my client-side application. Maybe this is because of my limited .Net knowledge. I wouldn't be surprised if this possibility does exist.


Take a look at Web Forms 2.0

Personally I'm not interested in them. There's a lot of pointless discussion comparing Web Forms and XForms. Depending on your point of view, you may be interested in them, so please take a look at them.


Non-Mozilla XForms implementations

In part 1 of the tutorial Mark Birbeck left a comment saying "I wouldn't want your readers to think that things don't exist unless they are implemented in Mozilla!" He hits the nail on the head. He's right about this and clearly points out I have a preoccupation for the Mozilla implementation over its alternatives.

If you want a full product review on 10 XForms engines, please read the XML.com article.


XForms actually for real!

I know, weblog writers have tendencies to make promises and don't keep them. Like people announcing taking a break from their weblog and continuing to write. Then announcing the break again, actually for real and still continue writing... This is not a complaint by the way ;-) Please be patient for part 2!


THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...


3 comments: Links to this post

Sunday, May 15, 2005

Blog roll

*** updated ***

Here it is then, a summary of my blog roll. I have also added some links to the right side of this page. I intend to change and update these from time to time. Thanks, Inès, for the HTML conversion. To get the gory details in OPML, click here.

No comments: Links to this post

Thursday, May 12, 2005

XForms tutorial part 1

THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...




Introduction

Initially it wasn't my intention to write a tutorial on XForms. In fact I was trying to find a solution to a real world problem. The reason I decided to use this as a basis for an XForms tutorial is that many people don't understand the purpose of XForms and similar techniques. With a simplified definition of my technical challenge this tutorial should convey the advantages of XForms over related techniques.


The challenge

When you're storing company data, one of the most fundamental design choices is the model you try to fit the data to. In many cases developers are used to forcing every possible data model to an ER-diagram for a classic relational database. Relational databases are very well suited for storing large ammounts of structured data and building efficient queries. Relational databases have been evolving for decades and have become very mature solutions providing various solutions to common practical issues.

Their weakness however is that real world data doesn't always match the theoretical structures assumed by ER-diagrams. In practice either the data is forced into an inadequate model or the model's complexity grows and harms the efficiency of the query algorithms.

The last few years, special purpose databases were introduced to solve these issues. At the same time, classic databases evolved in the same direction to offer additional modeling tools better suited for modeling semi-structured data. The XML database is born. Problem solved.


Whoa, stop right there!

What does that mean, semi-structured data? And what about the database-aware controls, like the way you clicketyclick forms in Microsoft Access?

Suppose you are storing a curriculum vitae - a resume for a job seeker. How would you model this in an ER-diagram? At least you whould have a table PERSON with basic data like names, social security numbers and bank accounts. You need related tables with ADRESSes and PHONE_NUMBERs. That's still structured data.

But then you want to store past WORK_EXPERIENCEs, EDUCATION, COURSEs, TEST_RESULTs, ABILITYs, LANGUAGEs, PREFERENCEs, etc. In addition you want more detailed information on EDUCATION like SUBJECTs with their grades. For specific TEST_RESULTs, you want to model the data fields in order to capture aspects for specific TESTs and make them available to the user. Tests results are different in many ways depending on the test and the work field for the job seeker. Secretary skills and management assessment tests cannot be modeled in the same table definition.

Even if you find a complex but adequate model for your needs, a huge effort is needed to provide usable graphical interfaces for data management. You find yourself building complex forms with nested one-to-many relationships to connect the pieces of data. You're making large aggregations of queries to output reports and documents displaying the data.

The key problem is that a detailed curriculum vitae does not fit in an ER-diagram well. Either the data is not described in full detail by a simplified model or you end up with a complex and hard to maintain model with many unused fields.

The key solution is to realize the nature of a curriculum vitae: it's a document! Use techniques that are meant to describe documents. Use XML!


The essence of XML

The main advantage of XML as a document description language is the increased number of degrees of freedom. Instead of allocating unused table space to capture for rare details, you define description tags that don't waste space when they're not used. Instead of forcing one-dimensional relations between data entities, you can allow reuse of data elements through the entire document. This prevents duplication of data definitions or hard to understand normalization steps.

Consider this:


<curriculumvitae>
    <personaldetails>
      <firstname>Jane</firstname>
      <lastname>Doe</lastname>
      <address>Churchillweg</address>
      <number>2</number>
      <numberaddition>b</numberaddition>
      <postalcode>1234AC</postalcode>
      <city>Lutjebroek a/d Greppel</city>
      <country>Nederland</country>
    </personaldetails>
    <workexperience>
      <company>Data flex technology</company>
      <jobtitle>Data typist</jobtitle>
      <jobdescription>
        Typing data in a legacy aplication.
      </jobdescription>
    </workexperience>
    <workexperience>
      <company>Supermerkati</company>
      <jobtitle>Sales representative</jobtitle>
      <jobdescription>
        Selling cheese in the cheese department
      </jobdescription>
    </workexperience>
    <education>
      <highschool>
        <name>Elzen Zicht</name>
        <level>C-</level>
        <description>
          Special treatment for children with learning
          disabilities.
        </description>
        <major>
          <name>Physics</name>
          <grade>A-</grade>
          <remarks>
            Received award for special efforts.
          </remarks>
        </major>
        <subject>
          <name>French</name>
          <grade>B+</grade>
        </subject>
        <subject>
          <name>Math</name>
          <grade>D-</grade> </subject>
      </highschool>
    </education>
</curriculumvitae>


Converting this to HTML can easily be done using an XSLT style sheet. XSLT style sheets offer very dynamic, expressive and declarative definitions to transform XML content to other XML structures. XSLT has been around since the early days of XML and is widely used in XML applications. XSLT is still growing in popularity and there is increasing demand for XSLT experience in job vacancy descriptions.

The XSLT to convert our XML sample to XHTML looks like this:


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
    <xsl:template match="/curriculumvitae">
      <html>
      <head>
      <title>CV for <xsl:value-of select="personaldetails/firstname/text()"/> <xsl:value-of select="personaldetails/lastname/text()"/></title>
      </head>
      <body>
      <h1>CV for <xsl:value-of select="personaldetails/firstname/text()"/><xsl:text> </xsl:text><xsl:value-of select="personaldetails/lastname/text()"/></h1>
      <h2>Personal details</h2>
      <xsl:apply-templates select="personaldetails"/>
      <h2>Work experience</h2>
      <xsl:apply-templates select="workexperience"/>
      <h2>Education</h2>
      <xsl:apply-templates select="education/*"/>
      </body>
      </html>
    </xsl:template>
    <xsl:template match="personaldetails">
      <table>
      <xsl:apply-templates/>
      </table>
    </xsl:template>
    <xsl:template match="firstname">
      <tr>
      <td>First name</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="lastname">
      <tr>
      <td>Last name</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="address">
      <tr>
      <td>Address</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="number">
      <tr>
      <td>Number</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="numberaddition">
      <tr>
      <td>Number addition</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="postalcode">
      <tr>
      <td>Postal code</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="city">
      <tr>
      <td>City</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="country">
      <tr>
      <td>Country</td>
      <td><xsl:value-of select="./text()"/></td>
      </tr>
    </xsl:template>
    <xsl:template match="workexperience">
      <h3><xsl:value-of select="company/text()"/></h3>
      <p><strong><xsl:value-of select="jobtitle/text()"/></strong></p>
      <p><em><xsl:value-of select="jobdescription/text()"/></em></p>
    </xsl:template>
    <xsl:template match="highschool">
      <h3>High school: <xsl:value-of select="name/text()"/></h3>
      <p>Level: <xsl:value-of select="level/text()"/></p>
      <h4>Description</h4>
      <p><xsl:value-of select="description/text()"/></p>
      <h4>Subjects</h4>
      <xsl:apply-templates select="major"/>
      <xsl:apply-templates select="subject"/>
    </xsl:template>
    <xsl:template match="major">
      <p><strong>Major in <xsl:value-of select="name/text()"/></strong><br/>
      Grade: <xsl:value-of select="grade/text()"/><br/>
      Remarks: <xsl:value-of select="remarks/text()"/></p>
    </xsl:template>
    <xsl:template match="subject">
      <p><strong><xsl:value-of select="name/text()"/></strong><br/>
      Grade: <xsl:value-of select="grade/text()"/></p>
    </xsl:template>
</xsl:stylesheet>


But what about Graphical User Interfaces?

That's the question. Instead of developing specific forms for a single purpose, I would like to use some sort of XSLT to generate a form. I can do that; I can generate an HTML form for the XML document using XSLT. But what if I want to add another workexperience? What if I want to save the data back to the server? Then I would need to translate the form data back to XML. It would require huge amounts of dynamic HTML to offer possibilities to extend the form with user controls and data handling.

Isn't there such a thing as an XSLT that generates a form, keeps the source document in memory, automatically translates changes in the form back to the source document and preferably dynamically displays changes in the source document in the form?

I started searching for this. First thing I found, was Wobzilla. Wobzilla does exactly what I'm describing here. But Wobzilla was a single developer effort that lead to an alpha quality product and is not maintained anymore.

Then I found Microsoft InfoPath. Slightly different, but does everything we need. Disadvantages: vendor specific, MS Office lock-in, hard to integrate in web applications or client side applications. But still useful if you decide to use it.

Finally I found the XForms specification. Main problem: there were no stable production quality implementations available. Until the Mozilla project started working on an XForms implementation.

Here we are: we have a challenge and a possible solution supported by W3C. How do we build an XForm we can use as GUI for our curriculum vitae?

I'll dive in to the technical stuff in part 2!




THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ MORE IN PART 5 OF THE XFORMS TUTORIAL...


6 comments: Links to this post
Subscribe to: Posts (Atom)