Validating XML

In the creation of a database, a data model and integrity constraints can create certainty in the structure and content of the data. But how do you enforce that kind of control when your data is just text in hand-editable files? Fortunately, validating files and documents can make sure that data fits constraints. In this tutorial, you will learn what validation is and how to check a document against a Document Type Definition (DTD) or XML Schema document.

Prerequisites

You should be familiar with the basic concepts of XML, and have a basic familiarity with XML Namespaces.

While this tutorial demonstrates validation using the Java language from the command line, experience with Java technology is not required to gain a thorough understanding.
 

System requirements

You will need JavaScript enabled on your browser.

This tutorial will help you understand the topic even if you read the examples rather than trying them out. If you do want to try the examples as you go through this tutorial, make sure you have the following tools installed and working correctly:

• A text editor: XML files, DTDs, and XML Schema documents are simply text. To create and read them, a text editor is all you need.
• You can manipulate and validate XML in any language where a validating parser is available. The bulk of the tutorial deals with the creation of documents, but you will also see how to build an application that uses a validating parser. XML support has been built into the latest version of Java (available at http://java.sun.com/j2se/1.4.2/download.html), so you won’t need to install any separate classes. (If you’re using an earlier version, such as Java 1.3.x, you’ll also need an XML parser such as the Apache project’s Xerces-Java (available at http://xml.apache.org/xerces2-j/index.html), or Sun’s Java API for XML Parsing (JAXP), part of the Java Web Services Developer Pack (available at http://java.sun.com/webservices/downloads/webservicespack.html).

If you have a different set of tools installed, you can use them instead. Just check the documentation for instructions on turning on validation. You can download C++ and Perl implementations of Xerces from the Apache Project at http://xml.apache.org.

P2P and XML in Business

Following the growth of business-to-business exchanges and supply chain management systems, the emergence of peer-to-peer (P2P) computing is likely to become another deployment arena for XML technology. Whether exchanging user messages, application state, or processing instructions, relaying information effectively is a critical component of any P2P application. By using XML system designers can establish rules for peer interaction that allow developers to build applications independently. From this perspective, one sees how, by facilitating this communication, XML plays an important role in P2P application design.

What is P2P?

As with any technology emerging under the media spotlight, P2P as a whole is open to misinterpretation. Much of the confusion surrounding the term “peer-to-peer” arises from companies applying the label to dozens of distinct types of system. For instance, SETI@home, the well-known distributed computing project designed to analyze data with the hope of finding extraterrestrial life, has little in common with the infamous Napster music community. Similarly, Groove Networks’ collaboration system cannot be directly compared to the Jabber Open Source project that focuses on instant messaging. Yet these disparate systems are all are touted as key elements of the P2P movement.

As a result one is hard pressed to find a common technical thread among these P2P applications. Complicating matters further, there exists no field monopolizing these initiatives, as notable contributions to P2P technology have been made in many areas. Nor is there a single industry sector driving the effort. Network equipment manufacturers, open source projects, educational institutions, and scores of unaffiliated independent programmers all have played an important role to further the development of the P2P systems.

Without a suitable definition in terms of technology or contributors, the industry is left to describe P2P in terms of the intent of its supporters. Framed this way, peer-to-peer is best defined as the set of technologies targeted at better utilizing resources that are networked together. Defining peer-to-peer as any system designed with the explicit intent to take advantage of under-utilized networking, disk space, processing, or user resources at the edges of the Internet is the best way to accurately depict the underlying movement while still encompassing all aspects of the technology.

Does P2P make sense?

The timing of this new interest in peer-to-peer technology is interesting. Just when IT managers have begun to adapt to the shift from client-server applications to web-based application services, users are showing new found interest in exploiting dormant resources on their desktops connected to networks. In fact, users are beginning to demand more control over their computing resources every day.

Whether creating chat rooms with colleagues or sharing files with clients directly, users want the ability to use applications without relying on IT departments to set up user accounts or create virtual private networks to support them. For years, IT administrators have been pressured to consolidate IT support operations by locking down corporate desktops and centralizing computing resources. Now they are being told that their systems are too rigid and don’t allow users enough control. Not surprisingly, the demand for new peer systems has been met with harsh resistance.

Many IT managers thought that their jobs would be getting more bearable as decreasing server costs allowed them to meet the budgetary constraints of their departments. The pendulum seems to be swinging once again as the indirect costs of under-utilized desktop computing resources have offset the hardware savings of server-centric IT systems. This current shift highlights the continuing oscillation from central to distributed control of computer systems. Those who witnessed the prior shifts, from mainframes to client-server applications and more recently from client-server applications to server-centric ASP architecture, should find the rationale behind P2P architectures vaguely familiar. Looking at computing architecture over the course of the last quarter century, one sees that the P2P movement is the just the most recent phase of this centralized-distributed cycle.

Despite the historical and theoretical justifications of P2P systems, the costs associating with developing, deploying, and supporting client application are not insignificant. So before starting a P2P crusade within an organization, one should be certain it makes economic sense. Although there is much discussion concerning this topic, any viable P2P system should offer benefits that cannot be achieved relying on another computing architecture that is less costly to maintain.

XML and Peer-to-Peer Technology

After determining that P2P technology is appropriate for an IT project, there are several design challenges that will have to be solved before any development can begin. Since pure P2P systems have no central servers for dispatching information between peers, devising a mechanism for peers to communicate is a critical aspect P2P design. And efficiently distributing and storing application data for peer access is not a trivial task since data often has to reside locally on the peer for processing. And managing the updates to the peer application components themselves is of paramount concern as even a simple bug fix can lead to a distribution nightmare. It is no coincidence these are the areas in P2P technology that benefit the most from XML.

Messaging

XML offers an ideal mechanism to transfer short, structured messages between peer applications. XML can be easily customized for specific P2P systems and readily transmitted over today’s Internet protocols. XML data can be encrypted using existing technologies, making it an ideal candidate for secure messages. There are already several implementations of XML-based messaging schemes, including SOAP and XML-RPC.

Data Storage

Utilizing XML to cache application data locally in P2P systems offers several advantages. Caching data in XML allows for more flexibility and easier retrieval than custom or unstructured formats, and it has a much smaller overhead than installing a relational database on each peer. Developers can take advantage of XML handlers to search, validate, retrieve, and manipulate the data needed to support the peer application. This approach will reduce the overall complexity of the P2P system. In many cases XML stores are easier to implement than storing unstructured data directly in the file system and require less system resources to operate than relational databases.

Application Deployment

XML can also be used to help manage the deployment of the application components to peers in the network — often one of the most difficult challenges of P2P systems. With the potential of having millions of peers interacting, having an effective process to distribute software updates is essential to the long-term success of any P2P system. One XML-based solution to this problem is Open Software Description (OSD). OSD files allow system architects to define the application components required for peer applications along with the location to download these components and any component dependencies. Effectively integrating OSD files into a P2P deployment strategy shifts the burden of software upgrades from the user to the P2P application itself. Each peer can verify that it has the most recent software components and automatically download upgrades if needed.

Netscape vs. Google

If Netscape was the standard bearer for Web 1.0, Google is most certainly the standard bearer for Web 2.0, if only because their respective IPOs were defining events for each era. So let’s start with a comparison of these two companies and their positioning.

Netscape framed “the web as platform” in terms of the old software paradigm: their flagship product was the web browser, a desktop application, and their strategy was to use their dominance in the browser market to establish a market for high-priced server products. Control over standards for displaying content and applications in the browser would, in theory, give Netscape the kind of market power enjoyed by Microsoft in the PC market. Much like the “horseless carriage” framed the automobile as an extension of the familiar, Netscape promoted a “webtop” to replace the desktop, and planned to populate that webtop with information updates and applets pushed to the webtop by information providers who would purchase Netscape servers.

In the end, both web browsers and web servers turned out to be commodities, and value moved “up the stack” to services delivered over the web platform.

Google, by contrast, began its life as a native web application, never sold or packaged, but delivered as a service, with customers paying, directly or indirectly, for the use of that service. None of the trappings of the old software industry are present. No scheduled software releases, just continuous improvement. No licensing or sale, just usage. No porting to different platforms so that customers can run the software on their own equipment, just a massively scalable collection of commodity PCs running open source operating systems plus homegrown applications and utilities that no one outside the company ever gets to see.

At bottom, Google requires a competency that Netscape never needed: database management. Google isn’t just a collection of software tools, it’s a specialized database. Without the data, the tools are useless; without the software, the data is unmanageable. Software licensing and control over APIs–the lever of power in the previous era–is irrelevant because the software never need be distributed but only performed, and also because without the ability to collect and manage the data, the software is of little use. In fact, the value of the software is proportional to the scale and dynamism of the data it helps to manage.

Google’s service is not a server–though it is delivered by a massive collection of internet servers–nor a browser–though it is experienced by the user within the browser. Nor does its flagship search service even host the content that it enables users to find. Much like a phone call, which happens not just on the phones at either end of the call, but on the network in between, Google happens in the space between browser and search engine and destination content server, as an enabler or middleman between the user and his or her online experience.

While both Netscape and Google could be described as software companies, it’s clear that Netscape belonged to the same software world as Lotus, Microsoft, Oracle, SAP, and other companies that got their start in the 1980’s software revolution, while Google’s fellows are other internet applications like eBay, Amazon, Napster, and yes, DoubleClick and Akamai.

What Is Web 2.0

The bursting of the dot-com bubble in the fall of 2001 marked a turning point for the web. Many people concluded that the web was overhyped, when in fact bubbles and consequent shakeouts appear to be a common feature of all technological revolutions. Shakeouts typically mark the point at which an ascendant technology is ready to take its place at center stage. The pretenders are given the bum’s rush, the real success stories show their strength, and there begins to be an understanding of what separates one from the other.

The concept of “Web 2.0″ began with a conference brainstorming session between O’Reilly and MediaLive International. Dale Dougherty, web pioneer and O’Reilly VP, noted that far from having “crashed”, the web was more important than ever, with exciting new applications and sites popping up with surprising regularity. What’s more, the companies that had survived the collapse seemed to have some things in common. Could it be that the dot-com collapse marked some kind of turning point for the web, such that a call to action such as “Web 2.0″ might make sense? We agreed that it did, and so the Web 2.0 Conference was born.

In the year and a half since, the term “Web 2.0″ has clearly taken hold, with more than 9.5 million citations in Google. But there’s still a huge amount of disagreement about just what Web 2.0 means, with some people decrying it as a meaningless marketing buzzword, and others accepting it as the new conventional wisdom.

This article is an attempt to clarify just what we mean by Web 2.0.

In our initial brainstorming, we formulated our sense of Web 2.0 by example:

Web 1.0		Web 2.0
DoubleClick	–>	Google AdSense
Ofoto	–>	Flickr
Akamai	–>	BitTorrent
mp3.com	–>	Napster
Britannica Online	–>	Wikipedia
personal websites	–>	blogging
evite	–>	upcoming.org and EVDB
domain name speculation	–>	search engine optimization
page views	–>	cost per click
screen scraping	–>	web services
publishing	–>	participation
content management systems	–>	wikis
directories (taxonomy)	–>	tagging (”folksonomy”)
stickiness	–>	syndication

The list went on and on. But what was it that made us identify one application or approach as “Web 1.0″ and another as “Web 2.0″? (The question is particularly urgent because the Web 2.0 meme has become so widespread that companies are now pasting it on as a marketing buzzword, with no real understanding of just what it means. The question is particularly difficult because many of those buzzword-addicted startups are definitely not Web 2.0, while some of the applications we identified as Web 2.0, like Napster and BitTorrent, are not even properly web applications!) We began trying to tease out the principles that are demonstrated in one way or another by the success stories of web 1.0 and by the most interesting of the new applications.

Like many important concepts, Web 2.0 doesn’t have a hard boundary, but rather, a gravitational core. You can visualize Web 2.0 as a set of principles and practices that tie together a veritable solar system of sites that demonstrate some or all of those principles, at a varying distance from that core.

DoubleClick vs. Overture and AdSense

Like Google, DoubleClick is a true child of the internet era. It harnesses software as a service, has a core competency in data management, and, as noted above, was a pioneer in web services long before web services even had a name. However, DoubleClick was ultimately limited by its business model. It bought into the ’90s notion that the web was about publishing, not participation; that advertisers, not consumers, ought to call the shots; that size mattered, and that the internet was increasingly being dominated by the top websites as measured by MediaMetrix and other web ad scoring companies.

As a result, DoubleClick proudly cites on its website “over 2000 successful implementations” of its software. Yahoo! Search Marketing (formerly Overture) and Google AdSense, by contrast, already serve hundreds of thousands of advertisers apiece.

Overture and Google’s success came from an understanding of what Chris Anderson refers to as “the long tail,” the collective power of the small sites that make up the bulk of the web’s content. DoubleClick’s offerings require a formal sales contract, limiting their market to the few thousand largest websites. Overture and Google figured out how to enable ad placement on virtually any web page. What’s more, they eschewed publisher/ad-agency friendly advertising formats such as banner ads and popups in favor of minimally intrusive, context-sensitive, consumer-friendly text advertising.

The Web 2.0 lesson: leverage customer-self service and algorithmic data management to reach out to the entire web, to the edges and not just the center, to the long tail and not just the head.

Akamai vs. BitTorrent

Like DoubleClick, Akamai is optimized to do business with the head, not the tail, with the center, not the edges. While it serves the benefit of the individuals at the edge of the web by smoothing their access to the high-demand sites at the center, it collects its revenue from those central sites.

BitTorrent, like other pioneers in the P2P movement, takes a radical approach to internet decentralization. Every client is also a server; files are broken up into fragments that can be served from multiple locations, transparently harnessing the network of downloaders to provide both bandwidth and data to other users. The more popular the file, in fact, the faster it can be served, as there are more users providing bandwidth and fragments of the complete file.

BitTorrent thus demonstrates a key Web 2.0 principle: the service automatically gets better the more people use it. While Akamai must add servers to improve service, every BitTorrent consumer brings his own resources to the party. There’s an implicit “architecture of participation”, a built-in ethic of cooperation, in which the service acts primarily as an intelligent broker, connecting the edges to each other and harnessing the power of the users themselves.

Opensource PHP framework Symfony

Symfony based on the best practices of web development, thoroughly tried on several active websites, symfony aims to speed up the creation and maintenance of web applications, and to replace the repetitive coding tasks by power, control and pleasure.

Symfony provides a lot of features seamlessly integrated together, such as:

• simple templating and helpers
• cache management
• smart URLs
• scaffolding
• multilingualism and I18N support
• object model and MVC separation
• Ajax support
• enterprise ready

Do you want to know more? Get started and join the growing symfony community now!

More Details