Cup of Cafe con Leche XML News and Resources

Quote of the Day

If you're data is really simple, maybe just a set of key/value pairs, and if both the key and the value are strings, and if the consequences of bad data are negligible, and if there's no possibility that there will ever be any additional complexity, then sure, maybe a flat text file is all you need.

On the other hand, the difference between:

fruit=pear
vegetable=carrot
topping=wax

and

<doc>
<fruit>pear</fruit>
<vegetable>carrot</vegetable>
<topping>wax</topping>
</doc>

isn't really that large, is it? (Or maybe you think it is, de gustibus non est disputandum.) Except, of course, that in the XML case, you don't have to write or maintain the code for the parser, unit tests for the parser, or documentation for the parser in every language (programming and documentation), and for every platform, supported by your application. Nor do you have to worry about how to parse the file when the data contains spaces or new lines or Chinese characters. And some day, when the data is just a tiny bit more complex, you won't have to devise some clever hack for extending the format. You'll just use XML.

--Norm Walsh
Read the rest in Defending the tax

Today's News

The Web Accessibility Initiative has published Web Accessibility for Older Users: A Literature Review. "This document is intended to provide an overview of currently available literature about the needs of older adults with functional impairments accessing the web. It will compare how well these requirements are addressed and communicated by the WAI guidelines. This early version is intended to elicit comment and feedback on the literature collected and discussed so far. In particular we are interested in whether there are gaps in our coverage, or key resources overlooked. It should be noted that this is a work-in-progress and that not all sections are yet complete."

Permalink to Today's News | Recent News | Today's Java News on Cafe au Lait | The Cafes | Older News | E-mail Elliotte Rusty Harold

Recommended Reading

Selected content that might have some relevance or interest for this site's visitors:

You can also see previous recommended reading or subscribe to the recommended reading RSS feed if you like.

Recent News

Wednesday, May 14, 2008 (Permalink)

I am pleased to announce that my latest book, Refactoring HTML has been released by Addison Wesley. This book endeavors to improve the design of existing web sites along multiple axes: maintainability, security, attractiveness, and performance. It does this by moving sites to web standards: XHTML, CSS, and REST.

Rather than approaching this as a big bang project, small changes can be made in small steps that offer linear improvement. You don't need to spend months of developer time and thousands of dollars before you see any payback. You can improve your site some today, and then some more tomorrow. Refactoring a web site doesn't require large blocks of uninterrupted development time. Add up enough small changes in the little pieces of time scattered throughout the workday, and before you know it, your site is dramatically improved.

Not convinced yet? Let me offer a brief excerpt from Chapter 1:

Refactoring. What is it? Why do it?

In brief, refactoring is the gradual improvement of a code base by making small changes that don’t modify a program’s behavior, usually with the help of some kind of automated tool. The goal of refactoring is to remove the accumulated cruft of years of legacy code and produce cleaner code that is easier to maintain, easier to debug, and easier to add new features to.

Technically, refactoring never actually fixes a bug or adds a feature. However, in practice, when refactoring I almost always uncover bugs that need to be fixed and spot opportunities for new features. Often, refactoring changes difficult problems into tractable and even easy ones. Reorganizing code is the first step in improving it.

The concept of refactoring originally came from the object-oriented programming community, and dates back at least as far as 1990 (William F. Opdyke and Ralph E. Johnson, “Refactoring: An Aid in Designing Application Frameworks and Evolving Object-Oriented Systems,” Proceedings of the Symposium on Object-Oriented Programming Emphasizing Practical Applications [SOOPPA], September 1990, ACM), though likely it was in at least limited use before then. However, the term was popularized by Martin Fowler in 1999 in his book Refactoring (Addison-Wesley, 1999). Since then, numerous IDEs and other tools such as Eclipse, IntelliJ IDEA, and C# Refactory have implemented many of his catalogs of refactorings for languages such as Java and C#, as well as inventing many new ones.

However, it’s not just object-oriented code and object-oriented languages that develop cruft and need to be refactored. In fact, it’s not just programming languages at all. Almost any sufficiently complex system that is developed and maintained over time can benefit from refactoring. The reason is twofold.

  1. Increased knowledge of both the system and the problem domain often reveals details that weren’t apparent to the initial designers. No one ever gets everything right in the first release. You have to see a system in production for a while before some of the problems become apparent.

  2. 2. Over time, functionality increases and new code is written to support this functionality. Even if the original system solved its problem perfectly, the new code written to support new features doesn’t mesh perfectly with the old code. Eventually, you reach a point where the old code base simply cannot support the weight of all the new features you want to add.

When you find yourself with a system that is no longer able to support further developments, you have two choices: You can throw it out and build a new system from scratch, or you can shore up the foundations. In practice, we rarely have the time or budget to create a completely new system just to replace something that already works. It is much more cost-effective to add the struts and supports that the existing system needs before further work. If we can slip these supports in gradually, one at a time, rather than as a big-bang integration, so much the better.

Many sufficiently complex systems with large chunks of code are not object-oriented languages and perhaps are not even programming languages at all. For instance, Scott Ambler and Pramod Sadalage demonstrated how to refactor the SQL databases that support many large applications in Refactoring Databases (Addison-Wesley, 2006). However, while the back end of a large networked application is often a relational database, the front end is a web site. Thin client GUIs delivered in Firefox or Internet Explorer are everywhere, replacing thick client GUIs for all sorts of business applications, such as payroll and lead tracking. Adventurous users at companies such as Sun and Google are going even further and replacing classic desktop applications like word processors and spreadsheets with web apps built out of HTML, CSS, and JavaScript. Finally, the Web and the ubiquity of the web browser have enabled completely new kinds of applications that never existed before, such as eBay, Netflix, PayPal, Google Reader, and Google Maps.

HTML made these applications possible, and it made them faster to develop, but it didn’t make them easy. It didn’t make them simple. It certainly didn’t make them less fundamentally complex. Some of these systems are now on their second, third, or fourth generation; and wouldn’t you know it? Just like any other sufficiently complex, sufficiently long-lived application, these web apps are developing cruft. The new pieces aren’t merging perfectly with the old pieces. Systems are slowing down because the whole structure is just too ungainly. Security is being breached when hackers slip in through the cracks where the new parts meet the old parts. Once again, the choice comes down to throwing out the original application and starting over, or fixing the foundations; but really, there’s no choice. In today’s fast-moving world, nobody can afford to wait for a completely new replacement. The only realistic option is to refactor.

Most of the refactorings in this book focus on upgrading sites to web standards, specifically:

  • XHTML
  • CSS
  • REST

They are going to help you move away from

  • Tag soup
  • Presentation-based markup
  • Stateful applications

These are not binary choices, or all-or-nothing decisions. You can often improve the characteristics of your sites along these three axes without going all the way to one extreme. An important characteristic of refactoring is that it’s linear. Small changes generate small improvements. You do not need to do everything at once. You can implement well-formed XHTML before you implement valid XHTML. You can implement valid XHTML before you move to CSS. You can have a fully valid CSS-laid-out site before you consider what’s required to eliminate sessions and session cookies.

Nor do you have to implement these changes in this order. You can pick and choose the refactorings from the catalog that bring the most benefit to your applications. You may not require XHTML, but you may desperately need CSS. You may want to move your application architecture to REST for increased performance but not care much about converting the documents to XHTML. Ultimately, the decision rests with you. This book presents the choices and options so that you can weigh the costs and benefits for yourself.

It is certainly possible to build web applications using tag-soup table-based layout, image maps, and cookies. However, it’s not possible to scale those applications, at least not without a disproportionate investment in time and resources that most of us can’t afford. Growth both horizontally (more users) and vertically (more features) requires a stronger foundation. This is what XHTML, CSS, and REST provide.

Refactoring HTML is available now at Amazon, Safari, and other fine bookstores everywhere. The price is a very reasonable $39.99, and most stores are offering their customary discounts. (Amazon is 10% off at the moment.) I hope you enjoy it.

Tuesday, May 13, 2008 (Permalink)

The W3C Web Application Formats several new and update working drafts about Widgets:

A widget is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. A widget may run as a stand alone application (meaning it can run outside of a Web browser), or may be embedded into a Web document. In this document, the runtime environment on which a widget is run is referred to as a widget user agent and a running widget is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource. For more information about widgets, see the Widget Landscape document.

To be clear, this specification describes the requirements for desktop style widgets (akin to Dashboard, Opera Widgets, and Yahoo! Widgets). This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets.

The drafts include:

Monday, May 12, 2008 (Permalink)

The W3C Web Content Accessibility Guidelines Working Group has updated two working drafts on the Web Content Accessibility Guidelines:

Understanding WCAG 2.0

This document, "Understanding WCAG 2.0," is an essential guide to understanding and using Web Content Accessibility Guidelines 2.0 [WCAG20]. It is part of a series of documents that support WCAG 2.0. Please note that the contents of this document are informative (they provide guidance), and not normative (they do not set requirements for conforming to WCAG 2.0).

WCAG 2.0 establishes a set of Success Criteria to define conformance to the WCAG 2.0 Guidelines. A Success Criterion is a testable statement that will be either true or false when applied to specific Web content. "Understanding WCAG 2.0" provides detailed information about each Success Criterion, including its intent, the key terms that are used in the Success Criterion, and how the Success Criteria in WCAG 2.0 help people with different types of disabilities. This document also provides examples of Web content that meet the success criterion using various Web technologies (for instance, HTML, CSS, XML), and common examples of Web content that does not meet the success criterion.

This document indicates specific techniques to meet each Success Criterion. Details for how to implement each technique are available in Techniques and Failures for WCAG 2.0, but "Understanding WCAG 2.0" provides the information about the relationship of each technique to the Success Criteria. Techniques are categorized by the level of support they provide for the Success Criteria. "Sufficient techniques" are sufficient to meet a particular Success Criterion (either by themselves or in combination with other techniques), while other techniques are advisory and therefore optional. None of the techniques are required to meet WCAG 2.0, although some may be the only known method if a particular technology is used. "Advisory techniques" are not sufficient to meet the Success Criteria on their own (because they are not testable or provide incomplete support) but it is encouraged that authors follow them when possible to provide enhanced accessibility. Another support category is "Failure techniques", which describe authoring practices known to cause Web content not to conform to WCAG 2.0. Although failure techniques provide advisory information about certain authoring practices, authors must avoid those practices in order to meet the WCAG 2.0 Success Criteria.

Techniques for WCAG 2.0

"'Techniques and Failures for WCAG 2.0' provides information to Web content developers who wish to satisfy the success criteria of Web Content Accessibility Guidelines 2.0 (WCAG 2.0). Techniques are specific authoring practices that may be used in support of the WCAG 2.0 success criteria. This document provides "General Techniques" that describe basic practices that are applicable to any technology, and technology-specific techniques that provide information applicable to specific technologies. Currently, technology-specific techniques are available for HTML, CSS, ECMAScript, SMIL, ARIA, and Web servers. The World Wide Web Consortium only documents techniques for non-proprietary technologies; the WCAG Working Group hopes vendors of other technologies will provide similar techniques to describe how to conform to WCAG 2.0 using those technologies. Use of the techniques provided in this document makes it easier for Web content to demonstrate conformance to WCAG 2.0 success criteria than if these techniques are not used."

There's a lot of good information here. These should really be required reading for all HTML authors and web designers. The Techniques spec is probably the most practical, and where most readers should start.

Sunday, May 11, 2008 (Permalink)

The W3C XHTML 2 Working Group has posted the last call working draft of CURIE Syntax 1.0: A syntax for expressing Compact URIs. This is modeled after namespace URIs and qualified names. In brief, it defines a prefix for a known base IRI (a URI that can contain non-ASCII characters like é), then appends a colon and a local part. For example, the CURIE cafe:tradeshows.xml could be shorthand for http://www.cafeaulait.org/tradeshows.xml if the prefix cafe were mapped to the URL http://www.cafeaulait.org/. Exactly how prefixes are mapped to base IRIs is left to the specification of the documents in which the CURIEs appear. However if the CURIEs are in an XML document, then the namespaces in scope define the prefix mappings. The default namespace can be used for prefix-less CURIEs.

Frankly I'm surprised to see this. Namespaces and the namespace syntax are one of the notable failures of the XML ecosystem. Why someone would choose to imitate this now that we know better is beyond me. Based on experience with namespaces, I predict that the problems of moving CURIEs from one context to another are going to be especially problematic. Well, we've learned to live with (if not exactly like) namespaces. I guess we can get used to this.

Saturday, May 10, 2008 (Permalink)

Planamesa Software has released NeoOffice/J 2.2.3, a Mac port of OpenOffice 2.1 using a Java-based GUI. New features in this latest patch release include a Media Browser, native floating tool windows, trackpad magnify and swipe features. Features since 2.2.2 include grammar checking, importing images from scanners and cameras, QuickTime video, and menu bars that stay open when no window is present.

Friday, May 9, 2008 (Permalink)

SyncroSoft has released <Oxygen/> 9.2, $345 payware XML editor written in Java. Oxygen supports XML, XSL, DTDs, XQuery, SVG, Relax NG, Schematron, and the W3C XML Schema Language. According to the announcement, "Version 9.2 introduces a new XML Author edition specially tuned for content authors providing a well designed interface for XML editing by keeping only the relevant authoring features. The major additions in Oxygen XML Editor 9.2 are related to the WYSIWYG-like editing support and in particular to the DITA support. The general visual editing improvements include displaying the resolved content in the editor and navigation through links. With the new DITA features that include a new DITA map editor, actions for inserting conref links, a tight integration of the latest version of the DITA Open Toolkit, Oxygen XML Editor becomes the leading DITA editor and the easiest to use. Other improvements are browsing of XML databases using WebDAV connections, better handling of Chinese, Japanese and Korean (CJK) text, support for the Intel® XML Software Suite and multiple component updates."

Thursday, May 8, 2008 (Permalink)

The OpenOffice Project has posted the first beta of OpenOffice 3.0, an open source office suite for Linux, Solaris, and Windows that saves all its files as zipped XML.

The most immediately visible change to OpenOffice.org 3.0 is the new "Start Centre", new fresh-looking icons, and a new zoom control in the status bar. A closer look shows that 3.0 has a myriad of new features. Notable Calc improvements include a new solver component; support for spreadsheet collaboration through workbook sharing; and an increase to 1024 columns per sheet. Writer has an improved notes feature and displays of multiple pages while editing. There are numerous Chart enhancements, and an improved crop feature in Draw and Impress.

Behind the scenes, OpenOffice.org 3.0 will support the upcoming OpenDocument Format (ODF) 1.2 standard, and is capable of opening files created with MS-Office 2007 or MS-Office 2008 for Mac OS X (.docx, .xlsx, .pptx, etc.). This is in addition to read and write support for the MS-Office binary file formats (.doc, .xls, .ppt, etc.).

OpenOffice.org 3.0 will be the first version to run on Mac OS X without X11, with the look and feel of any other Aqua application. It introduces partial VBA support to this platform. In addition, OpenOffice.org 3.0 integrates well with the Mac OS X accessibility APIs, and thus offers better accessibility support than many other Mac OS X applications.

Older News