eXtensible Markup Language
I've heard a lot of talk (not necessarily recently, but in general) about whether or not XML is the wave of the future.
The arguments, both for and against, certainly have merits:
- Pro: The dream-like utopia of disparate business systems all unified with a single communications medium.
- Pro: A non-proprietary format for the universal exchange of data.
- Pro: Well-formed, standardized, and human-readable.
- Pro: Able to be extended through the use of namespaces.
- Con: Large/bloated: XML is delivered in ASCII mode (not binary), which gives us the human-readable merit. Also, data needs to be enclosed within a set of tags, adding overhead.
- Con: Many of the disparate business systems I've worked with don't understand XML. Needing an intermediary to not only create but parse/translate into the native language.
Certainly, for most, the merits outweigh the downfalls. In many cases the last two win out over the benefits of XML simply because of time and expense.
In addition to XML, is a host of technologies built upon it.
- XSLT - translate that XML to any other sort of format.
- RSS
- XHTML
- MathML - can't ever get away from math can you?
- SVG - scalable vector graphics, images via XML!
Virtually every programming language has support in some form for XML: VB/ASP (including .net), perl, php, python, c/c++, any many others.
I've seen a lot of development utilizing XML in some form or another. Mozilla uses XUL to define the user-interface; news is shared via RSS; API's share content in XML form for consumption by other services. The State of Massachusetts is requiring all of their official documents be stored in OASIS. Many websites advocate the use of XHTML, sometimes going as far to say that it should be XHTML Strict despite failing to use the correct Content-Type (text/xhtml+xml). Even your favorites/bookmarks can be stored and shared in XML form through the use of XBEL.
Tags
-
Design Considerations
-
XML
Revisions
-
1/22/2012 - Archived.
-
1/27/2006 - Article published.