XML (Extensible Markup Language)

Contributor(s): Tamas E. Doszkocs, Gerhard Hill, Fredrik Lindgren, Neil Yashinsky, David Linthicum and Maxine Giza

Extensible Markup Language (XML) is used to describe data. The XML standard is a flexible way to create information formats and electronically share structured data via the public Internet, as well as via corporate networks.

XML code, a formal recommendation from the World Wide Web Consortium (W3C), is similar to Hypertext Markup Language (HTML). Both XML and HTML contain markup symbols to describe page or file contents. HTML code describes Web page content (mainly text and graphic images) only in terms of how it is to be displayed and interacted with.

XML data is known as self-describing or self-defining, meaning that the structure of the data is embedded with the data, thus when the data arrives there is no need to pre-build the structure to store the data; it is dynamically understood within the XML. The XML format can be used by any individual or group of individuals or companies that want to share information in a consistent way. XML is actually a simpler and easier-to-use subset of the Standard Generalized Markup Language (SGML), which is the standard to create a document structure.

The basic building block of an XML document is an element, defined by tags. An element has a beginning and an ending tag. All elements in an XML document are contained in an outermost element known as the root element. XML can also support nested elements, or elements within elements. This ability allows XML to support hierarchical structures. Element names describe the content of the element, and the structure describes the relationship between the elements.

An XML document is considered to be "well formed" (that is, able to be read and understood by an XML parser) if its format complies with the XML specification, if it is properly marked up, and if elements are properly nested. XML also supports the ability to define attributes for elements and describe characteristics of the elements in the beginning tag of an element.

For example, XML documents can be very simple, such as the following:

<?xml version="1.0" standalone="yes"?>


<greeting>Hello, world!</greeting>

<response>Stop the planet, I want to get off!</response>


Applications for XML are endless. For example, computer makers might agree upon a standard or common way to describe the information about a computer product (processor speed, memory size, and so forth) and then describe the product information format with XML code. Such a standard way of describing data would enable a user to send an intelligent agent (a program) to each computer maker's Web site, gather data, and then make a valid comparison.

XML's benefits sometimes appeared revolutionary in scope shortly after it was introduced. However, as a concept, it fell short of being revolutionary. It also fell short of being the panacea. The over-application of XML in so many areas of technology diminished its real value, and results in a great deal of unnecessary confusion. Perhaps most damaging is the predictable behavior of many vendors that look to recast XML using their own set of proprietary extensions. Although some want to add value to XML, others seek only to lock in users to their products.

XML's power resides in its simplicity. It can take large chunks of information and consolidate them into an XML document ‑ meaningful pieces that provide structure and organization to the information.

This was last updated in December 2014

Continue Reading About XML (Extensible Markup Language)

Dig Deeper on Scripting languages



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I have had no problems workin with XML. We use it for our web services. The XML is passed into the web service which then extracts the data and sends it off to our i-Series for processing.
Hi Todd! Glad to hear you've been able to use XML without a hitch. Sounds like you've found an appropriate way to use it.
It is handy but by no means is it a solution for every problem. The nice thing I find is when working with the file in a .NET app, when the XML changes,  modifications are not a big deal to deal with. I find it much easier to work with XML in the .NET world then when we tried using them in the ILE world of the i-Series.
What has your experience with XML been like?
We have a number of our systems creating XML files for passing around information. It works well and we continue to consider it as a solution when planning out new functionality. 
Um.. how to say.. awesome.. intuitive.. love at first sight :)
Including XPath. As for XSL, it took some time to get used to its programming paradigm - but it was totally worth it.
See my example for blink testing through XSL:
How to use XML? I'm ACT-II that was our report,that's why i need to learn how to explain this topic to our classmates and instruction. 
An easy way to explain an XML file is that the schema of the file contains the all the information on the file layout. This allows multiple record formats to be included in the same file. You can have for example an order header, an ordered item and an ordered item customization all sent within the same file. Three separate elements.

<?xml version="1.0" standalone="yes"?>
<xs:schema id="NewDataSet" xmlns="" xmlns:xs="" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="OrderHeader">
<xs:element name="OrderID" type="xs:int" minOccurs="0" />
<xs:element name="USerID" type="xs:int" minOccurs="0" />
<xs:element name="SoldToCompany" type="xs:string" minOccurs="0" />
<xs:element name="SoldToAddress" type="xs:string" minOccurs="0" />
<xs:element name="SoldToCity" type="xs:string" minOccurs="0" />
<xs:element name="SoldToState" type="xs:string" minOccurs="0" />
<xs:element name="SoldToZipCode" type="xs:string" minOccurs="0" />
<xs:element name="SoldToCountry" type="xs:string" minOccurs="0" />
<xs:element name="ShipToCompany" type="xs:string" minOccurs="0" />
<xs:element name="ShipToAddress1" type="xs:string" minOccurs="0" />
<xs:element name="ShipToAddress2" type="xs:string" minOccurs="0" />
<xs:element name="ShipToAddress3" type="xs:string" minOccurs="0" />
<xs:element name="ShipToCity" type="xs:string" minOccurs="0" />
<xs:element name="ShipToState" type="xs:string" minOccurs="0" />
<xs:element name="ShipToZipCode" type="xs:string" minOccurs="0" />
<xs:element name="ShipToCountry" type="xs:string" minOccurs="0" />
<xs:element name="RepNumber" type="xs:string" minOccurs="0" />
<xs:element name="CustomerNumber" type="xs:string" minOccurs="0" />
<xs:element name="CustomerPONumber" type="xs:string" minOccurs="0" />
<xs:element name="MarkTag" type="xs:string" minOccurs="0" />
<xs:element name="RepPONumber" type="xs:string" minOccurs="0" />
<xs:element name="Notes" type="xs:string" minOccurs="0" />
<xs:element name="WebTicket" type="xs:string" minOccurs="0" />
<xs:element name="OrderNumber" type="xs:string" minOccurs="0" />
<xs:element name="DateCreated" type="xs:dateTime" minOccurs="0" />
<xs:element name="Company" type="xs:string" minOccurs="0" />
<xs:element name="Division" type="xs:string" minOccurs="0" />
<xs:element name="Warehouse" type="xs:string" minOccurs="0" />
<xs:element name="PriceAs" type="xs:string" minOccurs="0" />
<xs:element name="FreightTerms" type="xs:string" minOccurs="0" />
<xs:element name="FreightCharge" type="xs:string" minOccurs="0" />
<xs:element name="OrderItem">
<xs:element name="OrderItemID" type="xs:long" minOccurs="0" />
<xs:element name="OrderID" type="xs:long" minOccurs="0" />
<xs:element name="Quantity" type="xs:int" minOccurs="0" />
<xs:element name="ModelNumber" type="xs:string" minOccurs="0" />
<xs:element name="PartNumber" type="xs:string" minOccurs="0" />
<xs:element name="ListPrice" type="xs:double" minOccurs="0" />
<xs:element name="ExtListPrice" type="xs:double" minOccurs="0" />
<xs:element name="CostMultiplier" type="xs:double" minOccurs="0" />
<xs:element name="NetPrice" type="xs:double" minOccurs="0" />
<xs:element name="ExtNetPrice" type="xs:double" minOccurs="0" />
<xs:element name="SellMethod" type="xs:string" minOccurs="0" />
<xs:element name="SellMultiplier" type="xs:double" minOccurs="0" />
<xs:element name="SellPrice" type="xs:double" minOccurs="0" />
<xs:element name="PriceVersion" type="xs:string" minOccurs="0" />
<xs:element name="ProgramVersion" type="xs:string" minOccurs="0" />
<xs:element name="LineItemType" type="xs:string" minOccurs="0" />
<xs:element name="ProductType" type="xs:string" minOccurs="0" />
<xs:element name="Company" type="xs:string" minOccurs="0" />
<xs:element name="Division" type="xs:string" minOccurs="0" />
<xs:element name="Warehouse" type="xs:string" minOccurs="0" />
<xs:element name="MarkTag" type="xs:string" minOccurs="0" />
<xs:element name="CommissionPct" type="xs:double" minOccurs="0" />
I've always enjoyed XML, It's verbose nature, and schema validation make it an interesting way to move data around.  Unfortunately I believe that over time JSON will begin to overtake it.
I think XML is great, especially since I came up with the scheme for data exchange in August 1996, well before the first published XML standard.  In 1997 when I saw my scheme published as a proposed XML standard by W3C, I contacted the W3C and they told me that the idea was originally proposed to W3C in August 1995 and development of that standard began sometime in 1996. 

Darn, if I just had the idea 1 year earlier, I would have been considered the creator of XML.  But since I came up with the standard before it was even a proposed standard, I ended up creating the first enterprise solution using XML in 1996.

Unfortunately, technology is always changing the JSON seems to be more and more used over my XML. :(
Am I allowed to throw some water on this XML loving fire?

From the moment I first laid eyes on XML I didn't get it. It was easily readable, but only if you were an English speaking reader. In most applications the files quickly got far too large to manage, and for the longest time there were very few syntax validators, so a missed end tag or a single quote where there should have been a double quote would mean a runtime error that would be next to impossible to track down.

The other think I just really disliked right from the start was the externalization of configuration data that rightfully belonged closer to the code. If I have code that connects to a database, why are the database parameters in a separate file, somewhere else in the project where I can't readily see them or change them? If there is a problem at runtime, I want the code and the configuration at my fingertips, not in separate documents in separate formats of expression. In Java, annotation based configuration removed the need for much of the information that was previously stored in difficult to manage XML files. I loved the annotation approach so much, I actually wrote a book on how easy it was to use the ORM tool with nothing but annotations - throw all the XML away!

I am speaking largely from a developers standpoint, but I can say that the shift away from XML in software development is a strong one. Annotations, mentioned above, allow Spring, Hibernate and even Java EE applications to be written in a way that removes much of the need for XML. And even the build tool arena, where tools like ANT and Maven used XML and almost nothing else, are being replaced by tools like Gradle where things are configured using a simple DSL, and when more complicated work is required, the Groovy programming language. That was always the big problem with XML - it allowed you to do some things easily, but tough things that might require logic became impossible. The shift in the industry is away from XML and more towards DSLs like Gradle that can sprinkle a little Groovy magic on top when some more complicated logic is needed.

Of course, the key is always finding the right tool for the job. Some people can do amazing things with XML, and some jobs don't require anything more complicated than XML's structured syntax. But as a developer, I've never had an affection for XML.


Extensions de fichiers et formats de fichiers

Motorisé par: