A more interesting question is 'Is XML on the web trending up or trending down?' Clearly, it is trending down. For data transfer applications, XML is losing ground to JSON because JSON is simply a better data transfer format. And XHTML has failed to displace HTML in the marketplace. The benefit of clientside validation has proven to not be a benefit. I think you can argue, and in fact I did argue, that because of W3C's adventures with XML, the web itself may not have a future. The browser has a lot of problems, the worst of which are the security problems that came with Netscape Navigator 2. That was 12 years ago, and there has been no progress since that time in fixing the fundamental problems. There have been lots of patches on top of patches. Nothing more.

When building the right project team to complete a custom solution there are many forces at work. These include business drivers, technical drivers, and organizational and political motivations. Regardless of the business or organization there are three basic rules to follow in building a team to deliver a technical solution. The first is to involve the business before the team is even assembled. Each organization has certain technology standards that govern specific tools and products that can be used on a given project.

XML is a simple, flexible text format initially designed for large-scale electronic publishing. It is flexible, open, and human-readable, and can be learned easily. XML can also be generated, parsed, analyzed, and transformed easily. It's no wonder that XML has been widely used for server-side computing: J2EE, .NET, and Web services.

Since the horrific events of September 11, 2001, the federal government has intensified its efforts to improve communications, collaboration, and information sharing between government and private sector agencies at all levels. The task of creating a seamless system of data and communication between disparate agencies has faced both technological and political obstacles.

In this article I am going to introduce you to the latest version of the Berkeley DB XML, version 2.2.8. Berkeley DB XML (BDB XML) is built on top of the well-known Berkeley Database (BDB). BDB XML is an open source, native XML database. Like its ancestor, BDB, it's an embedded database. It provides APIs for the Java, C++, Perl, Python, PHP, and Tcl languages. It supports the popular XML query languages XQuery and XPath 2.0. I will show you how to use BDB XML in two ways. This month I will introduce the BDB XML shell, and next month we will explore using BDB XML with Java. BDB XML has a lot of features, and I will try to cover the most important ones.

Imagine a fresh business relationship between ACME Corporation and Partner. As a result of this relationship, ACME wants to grant Partner limited access to one of its core internal applications. They do this, naturally, by exposing a Web service.

The Semantic Web is a hot topic in information circles today, and its adoption will largely depend on stakeholders understanding its potential benefits and tools vendors providing an easy entry for developers to learn and work with its related technologies.

The Department of Defense (DoD) Discovery Metadata Specification (DDMS) describes the DOD's preferred approach for decorating data assets with metadata. By providing a common convention for metadata, the DoD is building a common system for asset discovery, search, description, consumption, and security. This article provides a summary of the DDMS's purpose, structure, and capability. Upon completion the reader should have a basic understanding of the DDMS and should know where to go to get more detail and related materials. All questions regarding this article should be directed to Michael Sick at mike@serenesoftware.com.

Before the information age, car manufacturers only made cars, libraries only stored books, and newspapers only printed the news. Now, however, companies from all industries are realizing that in addition to what they do, they are also publishers, and there is a learning curve.

Web services will continue to play a vital role within enterprises, as companies strive to create cost-effective solutions that can be integrated into existing infrastructures. J2EE and Microsoft's .NET are the two primary platforms used in Web services. And while these two platforms continue to be actively developed, they are still in their infancy. How these platforms are developed is critical for the continued viability of Web services.

The Web has become the world's greatest repository of information on anything and everything. It's extremely useful - as long as you can find what you're looking for. Despite the arrival of Google and other powerful search tools, information seekers can't always connect with the most relevant information.

Despite a shortage of sophisticated XML query tools, Internet demands have forced companies to present their data in various formats. In one sense little has changed, as SQL queries have long been used to combine data for different purposes and audiences.

A few years ago there was no indication that XML could play an important role in computer-based process control. However, fast development and the spread of XML to different fields, and emerging trends in the field of automation, have changed the situation tremendously.

The end of the year is here again, a time when we traditionally take a long look at the progress we've already made and then turn our eyes toward the future, attempting to forecast the year to come.

Web services provide a way to allow efficient communication between disparate services. For years, enterprises have struggled to find reliable, cost-effective ways to integrate and automate critical processes between different application packages.

As XML has grown more prevalent as a data delivery mechanism, so too has the need to use it for presentation in a wide variety of reporting formats. XML is useful for more than just the delivery of information, however.

A few years ago, integrating applications simply required putting the right middleware in place. Today, however, the proliferation of different middleware approaches and technologies has complicated matters.

It occurs to me that my choice of title for this guest editorial may be at least partially influenced by the recall-induced elections in California (can you see the Arnie connection?). But this column is not about politics; it's about a new, industry-standard ecosystem built around XML to address today's business integration and process automation challenges.

This column may require a little patience on your part, but I think it will be worth it in the end. Let's start with a simple premise: within a year, nearly everyone reading these words will be deeply impacted by Sarbanes-Oxley, yet many have never heard of it.

When we at Antarctica start talking to a potential customer or partner, they say, 'That's Tim Bray's company? So this is XML-based data visualization?' And we have to say, 'No, it's ordinary database visualization. But because it's modern software, there's a lot of XML in the plumbing.' And in this there's a lesson.

In these cynical, post-bubble times, most chief information officers are rightfully dismissive about new technologies that promise to boost efficiency or customer service...but once in a while the claims are very true. Stylesheets can make application development cheaper and faster while increasing customer satisfaction.

I've been focused on defining product strategy for business integration software for the past seven years. During that time I've watched XML go from being a fledgling document standard with lots of potential to a core technology that is critical for business integration. In this article, I'm going to discuss some of the reasons behind XML's meteoric rise in the business integration space and some of the ways we at IBM are leveraging XML in our integration products.

In the history of XML to date, its role in application development has been mostly on the edge - it has been used primarily as the format for applications to communicate with each other, as a way to serialize data or configuration information, or for some other use at the 'front door' of the application. The internal data model and processing that made applications run were entirely driven by objects (Java, C#, or what have you), relational database schema, and the like. Developers used the same approach to data modeling they always had and leveraged XML on the outside of their applications.

The incompatibility of today's proprietary file formats goes well beyond the inconvenience of, say, unreadable e-mail attachments. It raises the larger issue of ownership - and cost of ownership. The data in your spreadsheet, the content in your business presentation, the words in your word processor - all of these belong to you. You created them.

I'm frequently asked about the difference between portability and interoperability, and am often surprised at how many people refer to one when they mean the other. On the surface, the terms are pretty understandable: interoperability means that different systems will work together.

The hardest part of writing transactional Web applications is finding a way to produce dynamic pages. The main underlying component of these pages, HTML forms, was added to what was originally a static, document-based standard, to allow the simple exchange of data between the user and the Web site. The more complex the information and the more sophisticated the interaction, the harder it's been to create these pages.

Do you want to understand our industry? Forget the big-name industry pundits and think-tanks. Look to the great poets like Donne and Shakespeare. You can't go wrong. The great poets can provide a long-term, human perspective on how we think, dream, and scheme. That insight is useful even in the new world of Web services and pervasive computing.

A few years ago at an early XML conference, an attendee made the point that XML was such a useful technology for data portability that it would eventually become ubiquitous - part of every tool, server, and application. He went on to predict that XML would become so commonplace that the idea of attending an XML conference would eventually seem silly. 'In a few years, a conference on XML will seem as ridiculous as a conference on ASCII would today,' he quipped.

The challenge of integrating software and systems will always be with us. In the brief but turbulent history of information technology, creation and destruction go hand in hand. Old technologies and approaches give way to new ones, sometimes quietly and sometimes with a fight. Yet, in this maelstrom of activity one thing remains unchanged. Our desire to solve bigger and more important business problems breeds increasing complexity. To battle this complexity we divide and conquer. We don't want to reinvent the wheel.

No standards movement in the history of the software industry has garnered as much attention or support as Web services. After the previous decade's failed attempts to reach unity, the industry has lauded the promise of more flexible, open, and interoperable software as a revolution and a breath of fresh air.

Better known in the i-technology world as enterprise application integration (EAI), B2B integration, or middleware, integration involves connecting internal systems with external business partners, customers, and suppliers. Integrating systems running on heterogeneous platforms, typically developed in different programming environments and managed by different groups (or different companies), is quite a complex task.

Questions about Web services and their uptake in financial services create a very black/white answer set. Some claim there's no usage; others say critical mass has been reached. The answer is somewhere in the middle.

Joel Spolsky, a long-time blogger who frequently publishes interesting software development observations, recently wrote a seminal piece entitled 'The Law of Leaky Abstractions'(www.j oelonsoftware.com/article s/ LeakyAbstractions.html). I encourage you to take a few minutes to read it, especially if you're involved with XML Web services. It summarizes one of the growing and troublesome trends surrounding Web services development and tools.

The XML-DEV discussion list - the open, unmoderated list supporting XML implementation and development and managed by OASIS - recently considered the burning question of whether XML is complete...or is still missing something. Renowned XML expert Simon St. Laurent, who initiated the discussion, commented in his opening remarks that, looking at the three original aspects of XML - which he defines as syntax, linking, and styling - it looked to him like they may be close to done.

It's often said that history repeats itself - and by studying history we gain better insight into our current (and future) society. In the late 1800s the telegraph was immensely popular, but telegraphs only connected telegraph offices. Messages still had to be transcribed into a paper format and delivered to the appropriate person.

In the June issue of XML-Journal I mentioned that we need a set of best practices that rein in the complexities of XML Schema. The set offered at www.xfront.com is a great start, but they cater to the XML Schema extremists, and I'd like to modify them, offering some alternative best practices for 'the rest of us.

During the late '90s and the early part of 2000, many people were busily working in startup X or Y, gleefully anticipating an initial public offering and the promise of cashing in on the New Economy.

Rube Goldberg, Pulitzer Prize-winning cartoonist who illustrated complex ways to achieve easy results, saw his cartoons as 'symbols of man's capacity for exerting maximum effort to accomplish minimal results.' He believed there were two ways to do things: simple and hard, and that a surprising number of people preferred the latter.

Every large corporation is a publisher, whether or not it knows it. User manuals, installation guides, repair manuals, corporate information, even internal documents like employee handbooks take weeks to draft, finalize, publish, and distribute. Ask any corporate information specialist or librarian.

The inaugural issue of XML-Journal was published in the first quarter of the new millennium. Then just two years old, XML already seemed to hold almost unlimited promise, and few seemed to doubt that XML technologies had excellent prospects for the 21st century that lay ahead of us. But unlike most other turn-of-the-century technology, XML has flourished slowly and steadily, including through the dot-com meltdown.