Few would argue with the statement that XML had an immense impact on the development community, influencing almost every area of computer science, from XML-based game files to financial data exchanged between various distributed Wall Street trading systems.
XML, in and of itself, however, is a text-centric medium. Even domain-specific applications—such as RSS, which uses XML as a means to syndicate information—are essentially limited to propagating text information. Any reference to binary data typically takes the form of a link pointing to an external resource to be parsed, validated, and presented by the RSS reader, or in a more general sense, by the targeted XML-interpreting application.
But what if you wanted to include actual binary data in your XML document? Well, your options are limited...but there are options. Let's examine some of these options with a working example. Figure 1 presents the one picture that you just can't wait to include in your next XML document.
Figure 1: What if your XML document requires an image?
The first, and probably most obvious approach of including binary data such as this image in your XML document is to do exactly what RSS and many other XML derivatives are doing, which is to not include the binary data, per se, but instead include a link pointing to an external resource where the image can be found (Figure 2):
Figure 2: Perhaps the solution is to include a link pointing to an external resource where the image can be found. (Click images to enlarge.)
This works fine with an RSS document in which the link points to a valid URL containing the image. But it isn't difficult to see the limitations in this approach. When sending XML data in a domain where external URLs are not feasible, such as when financial data needs to be sent from one financial institution to another, this approach breaks down. The receiving party cannot click on a link to access the financial data residing on the sending server. In essence, this would remove the entire purpose of sending the XML data in the first place. Even with RSS, images are sometimes deleted from the server, and older RSS messages containing URL links to those images end up full of broken links.
So, at this point, you've come to the conclusion that URL insertion is simply not for you. You need to actually embed the binary data into the XML document. So how do you do that? Well, why can't you just stick the raw binary data composing the picture directly into the XML document (Figure 3)?
Figure 3: This code contains raw binary data.
The problem with doing this should be fairly obvious. Binary data can contain anything. In particular, it can contain characters that are treated specially by XML parsers, such as
So we can't just place the binary data directly into the XML document. Now what? Well, at this point some XML pundits will point out that this is one of the circumstances where the XML tag should be used (Figure 4).
Figure 4: Is this a job for the XML tag?
Indeed, this is the approach taken by many folks seeking to have XML documents contain data that typically has no place in an XML document. The tag is indeed meant to contain any data that should be effectively ignored by the XML parser. But the problem here is that while we get rid of the problem of having indicates to the parser that the section is over. Because of this, tags cannot be nested. And because of this, while we effectively minimized the chances of corrupting the XML document with binary data, we did not entirely eliminate it; characters like (and how can you make sure it does not?), we are in the same hole as we were before. Still, remains one of the more popular methods of including "additional" data in an XML document.
Finally, another common approach to embedding binary data in XML documents is Base64 encoding (Figure 5).
Figure 5: Ah, here's the answer! Base64 encoding!
Encoding your binary data in base 64 "maps" the binary data to printable characters, ensuring that bad characters do not show up in your XML document. This removes the threat of corrupting the receiving parser, but it does have drawbacks in terms of size and space. Base64-encoded data is about 33% larger in size than the original data. In terms of time, you also have to take into account the fact that the data has to be encoded on one side and subsequently decoded on the other. Still, if stability and accuracy take precedent to efficiency and space requirements, one cannot go wrong with Base64 encoding, especially since so many programming languages provide libraries for accomplishing this task, and there are many open-source and freeware standalone tools available as well.
Andrey Butov works as the lead developer for Antair Corporation. He can be contacted at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online