XML, the eXtensible Markup Language
The Standard General Markup Language is about two decades old. SGML was originally designed for processing large documentation sets, but SGML is neither a programming language nor a text formatting language. Instead, it's a meta-language that allows defining of customized markup languages. The most famous SGML-based language today is unquestionably HTML.
Because SGML has been around for two decades, many companies offer SGML tools and products and it's firmly entrenched in many high-end document-processing applications. SGML is quite a large language; however, understanding the basics isn't very difficult. It does contain many rarely used features which are harder to understand. Implementing a full SGML parser is difficult, and this has given SGML a reputation for fearsome complexity. This reputation isn't truly deserved, but it's been enough to scare many people away from using it.
XML, then, is a stripped-down version of SGML that sacrifices some power in return for easier understanding and implementation. It's still a meta-language, but many of SGML's lesser-used features and options have been dropped. The XML 1.0 specification is about 40 pages long, and a parser can be implemented with a few weeks of effort.
A mark-up language specified using XML looks a lot like HTML:
<?xml version="1.0"?> <!DOCTYPE myth SYSTEM "myth.dtd"> <myth> <name lang="latin">Hercules</name> <name lang="greek">Herakles</name> <description>Son of Zeus and Alcmena.</description> <mortal/> </myth>
An XML document consists of a single element containing sub-elements which can have further sub-elements inside them. Elements are indicated by tags in the text, consisting of text within angle brackets <...>. Two forms of elements are available. An element may contain content between opening and closing tags, as in <name>Hercules</name>, which is a name element containing the data Hercules. This content may be text data, other XML elements or a mixture of the two. Elements can also be empty, in which case they're represented as a single tag ending with a slash, as in <mortal/>, which is an empty stop element. This is different from HTML, where empty elements such as <BR> or <IMG> aren't indicated differently from a non-empty element such as <H1>. Also unlike HTML, XML element names are case-sensitive; mortal and Mortal are two different element types.
Opening and empty tags can also contain attributes, which specify values associated with an element. For example, text such as <name lang="greek">Herakles</name>, the name element has a lang attribute with a value of “greek”. In <name lang="latin">Hercules</name>, the attribute's value is “latin”. Another difference from HTML is that quotation marks around an attribute's value are not optional.
The rules for a given XML application are specified with a Document Type Definition (DTD). The DTD carefully lists the allowed element names and how elements can be nested inside each other. The DTD also specifies the attributes which can be defined for each element, their default values, and whether they can be omitted. For example, to make a comparison with HTML, the LI element, representing an entry in a list, can occur only inside certain elements which represent lists, such as OL or UL.
The document-type definition is specified in the DOCTYPE declaration; the above document uses a DTD called “mythology” that I invented for this article. The “mythology” DTD might contain the following declarations:
<!ELEMENT myth (name+, description, mortal?)> <!ELEMENT name (#PCDATA)> <!ATTLIST name lang ( latin | greek ) "latin"> <!ELEMENT description (#PCDATA)> <!ELEMENT mortal EMPTY>
I won't go into every detail of these lines, however, lines beginning with <!ELEMENT are element declarations. They declare the element's name and what it can contain. So, the myth element must contain one or more name elements, followed by a single description element, followed by an optional mortal element. (+, * and ? have the same meanings as in regular expressions: one or more, zero or more, and zero or one occurrence.) The mortal tag, on the other hand, must always be empty.
The third line declares the name element to have an attribute named lang; this attribute can have either of the two values “latin” or “greek” and defaults to “latin” if it's not specified.
A validating parser can be given a DTD and a document in order to verify that a given document is valid, i.e., it follows all the DTD's rules. This is quite different from HTML, since web browsers have historically had very forgiving parsers, and so relatively few people make any effort to write valid HTML. This looseness means that code to render HTML text is full of hacks and special cases; hopefully, XML won't fall into the same trap of leniency.
This article doesn't cover all of XML's features—I haven't discussed all the possible attribute types, what entities are or that XML uses Unicode, which enables XML processors to handle data written in practically any alphabet. For the full details of XML's syntax, the one definitive source is the XML 1.0 specification, available on the Web at the World Wide Web Consortium's XML page (see Resources). However, like all specifications, it's quite formal and not intended to be a friendly introduction or a tutorial. Gentler introductions are beginning to appear on the Web and on bookstore shelves.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide