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.

Naming

Pretty well any character is legal in an element or attribute name. You can use upper or lower case, accented letters, digits or punctuation. _ is good for separating words. You may not use a space. It is considered poor style to use -, . and :. Names cannot start with a number or punctuation or with the letters xml (in any case). Names are case sensitive.

Encoding

UTF-8 is the default encoding, but unfortunately the encoding could be any ruddy encoding ever invented. Using other encodings destroys XML as an interchange format. Don’t do it!

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

Schemas

You describe your little XML subgrammar by writing a DTD (Document Type Definition) file. Optionally, you can include the DTD inline inside your XML file. There are other more elaborate schema grammars including RELAX NG, Schematron, XSD and various other schemas.I like XSD (XML Scheme Definition) s the best.

Validation

Each schema has its corresponding technique for validating an XML file that the syntax is valid. If you use a DTD, here:

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 (extensible Stylesheet Language), CSS (Cascading Style Sheets), XLink and so forth. In the pipeline are XHTML (extensible Hypertext Markup Language), 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 offline to be as predigested and as compact as possible, e.g. Serialized 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 (Central Processing Unit) and ram heavy. You can use WBXML (Wireless Binary extensible Markup Language). 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 (Website Meta Language). 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 (Abstract Syntax Notation 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 (Graphic User Interface) 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 (A Neat Tool) 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 (Character DATA) 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 (Resource Development Framework) ontologies address this problem.

• 	recommend book⇒The Theory of The Leisure Class
  	by	Thorstein Veblen	978-0-14-018795-3	paperback
  	birth	1857-07-30 died: 1929-08-03 at age: 72	978-0-8488-1659-9	hardcover
  	publisher	Penguin	978-1-4114-6469-8	eBook
  	published	1994-02-01	978-0-942563-00-9	audio
  			B00A73AIMA	kindle
  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 anz abe books.co.uk amazon.cn amazon.co.uk abe books.de abe books.ca amazon.de amazon.ca amazon.es Chapters Indigo iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Google play amazon.it O’Reilly Safari junglee.com Powells Kobo Sony eBooks other stores
  Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

  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 serialized 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 (Institute of Electrical & Electronics Engineers) 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 serialized 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 (Operating System). 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). 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 NCE (Numeric Character Entities) 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 NCEs (Numeric Character Entities). Again the values of numeric character references are interpreted as Unicode characters — no matter what encoding you use for your document, e.g. &#xa9 for ©. These are only sporadically supported.
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 NCE s, will create the files easiest to read and compose manually, XML ’s saving grace.

Quoting

Writing

There are a number of ways of writing XML.

• For simple files just use println.
• Use the DOM method to build a tree in memory then transform it into a text stream with javax.xml.parsers.DocumentBuilder javax.xml.parsers.DocumentBuilderFactory, javax.xml.transform.Transformer, javax.xml.transform.TransformerFactory, javax.xml.transform.dom.DOMSource.
• Use XML serialization You won’t have to write much code, but you won’t have any control over precisely what the stream looks like.
• use SAX to build a tree in memory then transform it into a text stream with org.apache.xml.serialize, org.xml.sax
• Use JavaEE XMLStreamWriter.
• Use a commercial code generator such as Liquid XML or Stylus XML tools.

XML Serialization

Tools

Books

	recommend book⇒Learning XML, second edition
	by	Erik T. Ray	978-0-596-00420-0	paperback
	publisher	O’Reilly	978-0-613-92344-6	hardcover
	published	2003-09-23	978-1-4493-7887-5	eBook
			B0043D2EAE	kindle
abe books anz abe books.co.uk amazon.cn amazon.co.uk abe books.de abe books.ca amazon.de amazon.ca amazon.es Chapters Indigo iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Google play amazon.it O’Reilly Safari junglee.com Powells Kobo Sony eBooks other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

	recommend book⇒Java and XML
	by	Brett McLaughlin, Justin Edelson	978-0-596-10149-7	paperback
	publisher	O’Reilly	978-0-596-55228-2	eBook
	published	2006-12-08	B0043EWVGU	kindle
Covers SAX2, DTDs, XML Schema, XSL, JDOM, JAXP, JAXB, RSS and remote procedure calls with XML.
abe books anz abe books.co.uk amazon.cn amazon.co.uk abe books.de abe books.ca amazon.de amazon.ca amazon.es Chapters Indigo iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Google play amazon.it O’Reilly Safari junglee.com Powells Kobo Sony eBooks other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

	recommend book⇒XML Pocket Reference
	by	Simon St. Laurent, Michael James Fitzgerald	978-0-596-10050-6	paperback
	publisher	O’Reilly	978-1-4493-7911-7	eBook
	published	2005-08-15	B0093SZ14U	kindle
abe books anz abe books.co.uk amazon.cn amazon.co.uk abe books.de abe books.ca amazon.de amazon.ca amazon.es Chapters Indigo iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Google play amazon.it O’Reilly Safari junglee.com Powells Kobo Sony eBooks other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More