XML : Java Glossary

The Basics

XML was designed to make it easy to write a parser. I think this was an unfortunate decision. Only a handful of people in the world will ever write an XML parser, but hundreds of thousands have to compose XML. They should have designed it to be easy and terse to write. For example, its mandatory quotes around each field are there solely for the convenience of the parser writer. The tag names in the </mytag;> are redundant, and should be optional. They are not needed at all in XML designed solely for machine consumption. Even in human-read XML, they add nothing on the innermost nest on a single line.

Encoding

<?xml version="1.0" encoding="UTF-8" ?>
<!-- explicit encoding specification -->
<!-- The space before the ?> is optional -->

Schemas

Validation

Parsing

I personally detest XML, however, it has caught on like a cocaine wave. It must have some redeeming features.

XML Benefits

• XML is the latest fad. Almost every program is learning to import and export data in XML format, which makes it a lot easier to glue programs created by different people together.
• It unifies the grammar of thousands of little files so that you don’t have to learn the syntax quirks of each one.
• It is relatively easy to whip up a DTD to describe an XML grammar for some little data file. That DTD is all you need to generate a parser.
• The XML files can be viewed or composed by humans using a text editor.
• XML is about as simple a grammar as you can get.
• XML can work with almost any 8-bit or 16-bit character set.
• XML is good at handling hierarchical data.
• You can have Pick OS-like data, with arbitrarily long fields, and arbitrarily repeated fields.
• XML is platform independent. It has no big-little endian problems.
• It is possible to parse XML without writing a DTD. This process presumes the XML file is perfectly formed.
• XML search engines can take into account the tag context, e.g. "Washington" inside tag <state>, <president>, <mountain>, <moviestar>. An XML search engine can show you want tags in found and let you choose the relevant ones.
• XML settles on Unicode character encoding to allow transmitting data in any language, though it does require clumsy entity encoding/decoding.
• A program does not need to understand the entire structure of a file. It can just pick out the tags of interest. This means new tags can be easily added without disturbing existing software that uses the file.

XML Drawbacks

• XML is incredibly fluffy and repetitive. It wastes bandwidth in transmission. You must compress it. Happily, ZIP-style compression works very well on XML. Unfortunately, you have to fluff it back up to process it, wasting RAM with unprecedented abandon. In practice no one does compress it.
• It takes up huge amounts of RAM and disk space to store it.
• The DOM parse tree considers every space significant, even spaces between tags, even spaces for indenting, even trailing spaces on a line, even double spaces embedded in data.
• There is no mechanism to describe the types of the data. To XML, everything is a string. There is no way to specify a field must be numeric, that in needs two decimal places, that it must represent a date in some range, that it must not have accented letters, that it be restricted to certain punctuation, or be one of a certain set of legal values. There are scores of tack-ons trying to fix this and other shortcomings turning the simple XML into a tower of Babel.
• You can’t use the XML files directly, they need to be parsed first. Perhaps some day there will be pre-parsed, compact, computer-friendly versions of XML. I have heard rumour such a beast called XMLC has been proposed.
• It uses HTML’s fluffy system of entities such as &nbsp;
• There are a raft of recommendations surrounding XML, such as XPath, XPointer, XSL, CSS, XLink and so forth. In the pipeline are XHTML, Metadata and Namespaces and a Schema system. XML is fast becoming very complicated, because it is not really standalone. You need added extras to make it usable. Competing standards will have to fight it out. The #1 reason XML caught on was its raging-idiot simplicity. Now it has not even that advantage.
• XML advocates say “Memory is cheap and bandwidth is cheap, so what the hell, let’s squander it.” However, this is not true with handhelds. Memory consumes battery power, the main limit today of handheld capabilities. Bandwidth consumes radio air time and battery time. We are running out of broadcast frequencies. You can’t manufacture more of them once the channels are filled, just use them more efficiently. Further, the delays caused by bloated XML packets consume precious people time, and frustrate the heck out of users completely needlessly.
• In an Applet or a hand held device, memory for data and code is at a premium. You normally carefully massage the data off-line to be as predigested and as compact as possible, e.g. serialised objects. As well as being fat, XML needs considerable processing before it can be used. This consumes RAM for both data and code, and battery power to do the massaging.
• There is no standard way to compress XML. You can use ZIP which is very cpu and ram heavy. You can use WBXML (Wireless Binary XML). The problem is on receipt, it is fluffed back up to regular XML then parsed, so it is has even more parsing overhead that regular XML. There are other compressed formats ASN-1 and WML. In practice most XML gets sent in its outrageously fluffy default form. People think XML files are always tiny little 1K configuration files and so why worry. The point is once a format gets established, it gets used for all sorts of things the originators would never have dreamed of, like 3 gig image files. ASN.1 schemas now can be used to validate XML files. XML files with XML schemas can be automatically converted to ASN.1. ASN.1 files can be decoded 100 times faster than XML. I think it is time to start thinking of using ASN.1 instead of XML for large files, or for when they must me transported over the wire.
• There is sort of mania to convert everything to XML, even things for which it is only marginally well-suited.

  This obsession of XMLing everything (build scripts, database mapping, setup & configuration,… etc.) without proper GUI tools to intelligently and efficiently edit and maintain such data contradicts the very fundamental role of the programmers’ profession.
  ~ Hani Hammami

• You pay for forcing all data into the XML mould in the circumlocutions necessary to say everything in XML, e.g. about 8 lines of code to conditionally copy a file in ANT with XML.
• XML assumes all data in the universe come in the form of a tree. XML becomes a Procrustean bed if the data are not tree-structured.
• XML DTD uses a ugly syntax with gratuitous punctuation. #IMPLIED really means optional. #PCDATA means string , CDATA means literal string, <!ATTLIST means attributes.
• There are no standard tag names for XML. Everyone still codes postal addresses differently which means data exchange still requires custom coding. RDF ontologies address this problem.

• 	recommend book⇒The Theory of The Leisure Class
  		paperback	hardcover
  	ISBN13:	978-0-14-018795-3	978-0-8488-1659-9
  	publisher:	Penguin
  	published:	1994-02-01
  	by:	Thorstein Veblen
  This is one of the most amusing books I ever read. It is funny by being so on. He coined the terms conspicuous consumption and conspicous waste to explain modern status displays.
  abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz

  XML is an example of conspicuous waste, waste for waste’s sake. I find it morally repugnant. I reminds me of Roman Emperor Caligula who took a bite of a peach, tossed it away, then grabbed a fresh one. The authors went out of their way to create a bloated, ugly syntax.

What Should Replace XML?

• It needs to be a binary format for compactness. Files have to both be transmitted and stored. Size does matter. People think in terms of one page XML files, but they potentially could be gigabytes long. If XML becomes an established interchange format we will pay for the slop in XML trillions of times over. It is not good enough to say XML files will always be stored in compressed form. In my experience in practice XML files are never compressed. Files should be both compact and quick to process. XML as it stands is neither.
• It needs to be a binary format to ensure correctness. Human readable formats tempt people to manually compose documents that are almost syntactically correct, e.g. HTML. This is too sloppy for an interchange format. Consider how much better chance you have of getting a working program first time if someone sends you java byte code rather than Java source that may not even compile.
• It needs to be computer-friendly so that a program can rapidly find the data it wants without having to parse for delimiters of various flavours. If people want to examine the file detail for debugging, let them use a binary reader/editor. You could use counted strings rather than delimited strings and use integers to encode the field types so they can be used directly as table indexes. I would not go quite so far is to ask for a serialised tree of nodes, but push for a representation that can rapidly be turned into one.
• For giant files, the representation should not have substantially more overhead than the raw binary. There need to be ways of efficiently expressing repeating patterns. For example, there is no need for delimiters for fixed length data. There is no need for individual field identifiers for standard groupings of fields. You want to push as much as possible of the file format description into the descriptor file, out of the data file. The descriptor file need be transmitted only once. The data file will typically be transmitted again and again. There is no need to make the format simple, just compact and fast to process. All you need is a simple programmer’s interface to it. Only a handful of programmers ever need concern themselves with its inner structure.
• XML currently only allows for hierarchical trees of data. There are one or two other types of data out there in the world, (e.g. tables, relations, references, graphs) A universal interchange format should be a little more flexible. If it is worth doing, it is worth doing right. Obviously the format can’t be expected to handle every conceivable data structure and obsolete every specialised interchange format ever devised. However, XML is talking big about becoming universal and should deliver. It can’t even handle ordinary business data which is typically relational not strictly hierarchical.
• One possible example of the sort of inner structure I am thinking of is my HTML compactor project.
• The other thing it needs is in the DTD some information about the allowed data types, there need to be the usual bounded ints, IEEE floats, IEEE doubles, 8-bit encoded strings in some reasonably small number of character sets, with maximum and minimum lengths, as well as a variety of business types, such as zip, zip+4, state, country, Canusan phone, international phone, date, time, credit card number, latitude, longitude, etc. When someone is handing you data you need to know how clean it is. You need to know ahead of time the minimum and maximum enforced limits on various field sizes.
• Ideally the new binary format, or a variant of it would also handle the function HTML does now. This would, in a stroke, give four benefits:
  1. Much more compact transmissions, which means much faster transmissions and lighter loaded servers.
  2. No more syntax errors. In the process of converting to binary format all syntax would either have to be manually or automatically corrected. This means the browser no longer has to deal with both the official standard, and also all the common variant errors that people type. This means pages would always render properly. As it is, pages render properly only in the browser used by the author which forgives his particular errors. The binary protocol effectively blocks human HTML coding errors from getting out on the net.
  3. Faster rendering since the data would arrive already preparsed. The browser would know for example how big tables are before it had finished reading the entire file, and so could start rendering the top part of the document accurately immediately.
  4. Consider the total dollars invested in equipment in the world to transmit HTML, including servers, satellite links, fibre optic links, cable connections… In a stroke, you would double the capacity of that equipment to deliver HTML, simply by switching to a binary delivery format.

One possible candidate for the XML replacement job is the Java serialised object format. It can handle just about any data structure imaginable. It is platform independent. It has a simple DTD — Java source code for the corresponding class. Some claim it is Java-only. Not so. It is no more difficult for C++ to parse than any other similar newly concocted protocol. It is not tied to any hardware or OS. It is just that Java has a head start implementing it. Java can implement it with no extra overhead.

There have been some efforts made to patch up the shortcomings of XML, in fact there are dozens of them. XML is no longer simple any more. It is raggedy patchwork quilt. People were sucked in by the initial simplicity, then discovered that it was not really all that useful in its simple form. Schema was added to allow specifying types (but still only permitting strings). Yes we need a standard interchange format, but XML was only a back of the envelope stab at it. XML was destined to fail since it totally ignored so many factors in coming up with a good design.

One such effort is VTD Virtual Token Descriptor (VTD). A VTD record is a 64-bit integer that encodes the starting offset, length, type and nesting depth of a token in an XML document. Because VTD records don’t contain data fields, they work alongside of the original XML document, which is maintained intact in memory by the processing model.

Due to the stupidity, duplicity and/or greed of those promoting XML, we will likely be stuck with some committee-patched variant of it forever — something that will make even HTML look clean. We need a common data interchange format, but not so inept.

DTD

Here is a simple example:

DTD:

XML:

Schema

Handling Awkward Characters, XML’ Entities

HTML has scores of entities whereas XML has only five:

But what about awkward non-ASCII characters such as é and Ω and ⇔? There are six ways around the restriction that XML does not support the full set of HTML character entity references.

1. If you use UTF-8 encoding, you can use any Unicode characters plain without entification.
2. If you use an 8-bit encoding such as ISO-8859-1, you can stick to just 256 characters defined in that encoding.
3. You could use decimal NCRs (Numeric Character Entites) e.g. &#8364; for the euro sign €. Values of numeric character references are interpreted as Unicode characters — no matter what encoding you use for your document. To be perverse, you could use decimal numeric entity references or the basic entity references i.e.
   < ( &#60; ), & ( &#38; ), > ( &#62; ), " ( &#34; ), ' ( &#39; ).
4. You could write a DTD to create the additional alphabetic character entities references you need, e.g. &euro;
5. You could use hexadecimal NCRs (Numeric Character Enti€. Again the values of numeric character references are interpreted as Unicode characters — no matter what encoding you use for your document.
6. If you take a depraved pleasure in deformity, you could use the CDATA sandwich. Place pretty well whatever data you want, including raw (un-entified) <, > and &, within in a bizarre sandwich of characters namely: <![CDATA[ … ]]>

   e.g. <caption><![CDATA[Rah! <><><> Rah! & all that.]]> </caption>

• You compose XML “by hand” with a text editor.
• You are developing code and read XML files directly.
• You write code to generate XML directly without using any sort of XML package.

UTF-8 files using the basic five character-entity encodings, or ISO-8859-1, with the basic five character entities (possibly excluding &apos;) plus decimal NCRs, will create the files easiest to read and compose manually, XML’s saving grace.

Quoting

XML Serialization

Digitally Signing XML

Apache has written classes to make the work easier.

Books

	recommend book⇒Java and XML
		paperback
	ISBN13:	978-0-596-10149-7
	publisher:	O’Reilly
	published:	2006-12-08
	by:	Brett McLaughlin, Justin Edelson
Covers SAX2, DTDs, XML Schema, XSL, JDOM, JAXP, JAXB, RSS and remote procedure calls with XML.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com sony e-books abe books anz o’reilly safari

Learning More