October 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Experiences in writing XML documents

  • August 12, 2002
  • By Benoît Marchal
  • Send Email »
  • More Articles »

XML documents do not magically appear on hard disks. Somebody has to create them, in most cases by typing the required information. How do build this essential interface with the end-user? If budget allows it, the most flexible solution is probably to develop a brand new data entry that will be optimized for your XML vocabulary.

I did mention budgets. Depending on the vocabulary, such an application can be very expensive to write and maintain. It may be more effective to customize a standard editing package for your vocabulary.

In this article, I survey the three most popular paths to build XML user interfaces. I will compare their characteristics and include many links so you can download products and test for yourself.

XML Editors

XML editors are probably the best-kept secret in this industry. Engineers are familiar with technically oriented editors such as XML Spy (www.xmlspy.com) but few have tried their end-user counterparts.

The best editors in the later category, such as XMetaL (www.xmetal.com), Epic (www.arbortext.com) or Morphon (www.morphon.com) emulate word processors. The idea being that since users are already familiar with word processors, they will quickly learn the new editor.

Unfortunately you cannot download an XML editor and start writing immediately. The editor must be customized to your XML vocabulary, and that's an engineering job. It takes a DTD, or an XML Schema, style sheets and macros.

In practice XML editors offer a programming environment dedicated to XML document editing. If you are willing to invest in customization, you will find that there are few limits to what you can do: access a database, validate data, send document to a server, etc.

In practice, the word processor metaphor works best for publishing, web site and documentation management. XML editors can be frustrating when used for database-oriented applications.

XForms

XForms is a standard in development with W3C. At the time of writing, XForms is at the last call status meaning it's close to completion.

XForms aims to enhance HTML forms: it adds a few new controls (such as the slider), enhance existing ones (for example, upload can now connect directly to a digital camera), and support new options such as computed fields (for example, as you fill-in the order, the total changes) and form validation (for example, validate an address).

Perhaps more importantly the form saves an XML document. As for XML editors, you must provide an XML Schema and possibly style sheets or other rendering information. XForms though is better suited for database-driven applications.

You can find more information on XForms, including links to draft level implementations, at (www.w3.org/MarkUp/Form). If you would rather have a shipping commercial solution than a draft standard, turn to Adobe Acrobat (www.adobe.com/acrobat). PDF forms are not compatible with XForms but they export their data in XML.

XSLT Conversions

Last but not least come XSLT and conversion tools. Conversion may not be as glamourous as XML editors but it's a smart, cost-effective approach for many cases. It recognizes that there are hundreds of specialized data entry tools, that work well and with which users are familiar. Most of them can export to CSV files (comma-separated values) or similar formats. Why not turn those files in XML?

When the conversion is properly implemented, it is transparent to the end-user and it saves a lot of re-training too! Since XSLT requires an XML document, you have to pair it with a more basic convert such as XI (www.ananas.org/xi), XML-Convert (www.unidex.com), Mercator (www.mercator.com) or even a Perl script.

For Office documents, you will turn to UpCast (www.infinity-loop.de) or Xfinity Author wX (www.b-bop.com).

A Toolkit Mentality

When building an XML user interface, you are unlikely to find off-the-shelf packages that immediately work for you. The very nature of XML, its flexibility and extensibility, prevents it. For every solution, a small amount of development is needed but the good news is that there's a growing range of products and solutions to choose from.

Benoît Marchal is a Belgian developer and writer. He is the author of XML by Example (two editions), Applied XML Solutions, and Java Web Services. There's more on this topic at marchal.com.




Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel