csh
/
y.st.
forked from y.st./y.st.


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179
							<?xml version="1.0" encoding="utf-8"?>
<!--
                                                                                     
 h       t     t                ::       /     /                     t             / 
 h       t     t                ::      //    //                     t            // 
 h     ttttt ttttt ppppp sssss         //    //  y   y       sssss ttttt         //  
 hhhh    t     t   p   p s            //    //   y   y       s       t          //   
 h  hh   t     t   ppppp sssss       //    //    yyyyy       sssss   t         //    
 h   h   t     t   p         s  ::   /     /         y  ..       s   t    ..   /     
 h   h   t     t   p     sssss  ::   /     /     yyyyy  ..   sssss   t    ..   /     
                                                                                     
	<https://y.st./>
	Copyright © 2017 Alex Yst <mailto:copyright@y.st>

	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<base href="https://y.st./en/opinion/XML.xhtml" />
		<title>XML &lt;https://y.st./en/opinion/XML.xhtml&gt;</title>
		<link rel="icon" type="image/png" href="/link/CC_BY-SA_4.0/y.st./icon.png" />
		<link rel="stylesheet" type="text/css" href="/link/basic.css" />
		<link rel="stylesheet" type="text/css" href="/link/site-specific.css" />
		<script type="text/javascript" src="/script/javascript.js" />
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<nav>
			<p>
				<a href="/en/">Home</a> |
				<a href="/en/a/about.xhtml">About</a> |
				<a href="/en/a/contact.xhtml">Contact</a> |
				<a href="/a/canary.txt">Canary</a> |
				<a href="/en/URI_research/"><abbr title="Uniform Resource Identifier">URI</abbr> research</a> |
				<a href="/en/opinion/">Opinions</a> |
				<a href="/en/coursework/">Coursework</a> |
				<a href="/en/law/">Law</a> |
				<a href="/en/a/links.xhtml">Links</a> |
				<a href="/en/opinion/XML.xhtml.asc">{this page}.asc</a>
			</p>
			<hr/>
			<p>
				<a href="/en/opinion/XML.xhtml"><abbr title="Extensible Markup Language">XML</abbr></a> |
				<a href="/en/opinion/code_indentation.xhtml">Code indentation</a> |
				<a href="/en/opinion/free_culture.xhtml">Free culture</a> |
				<a href="/en/opinion/free_software.xhtml">Free software</a> |
				<a href="/en/opinion/holidays.xhtml">Holidays</a> |
				<a href="/en/opinion/misuse_of_words.xhtml">Misuse of words</a>
			</p>
			<hr/>
		</nav>
		<header>
			<h1><abbr title="Extensible Markup Language">XML</abbr></h1>
			<p>Extensible Markup Language</p>
		</header>
<h2>Cleaner than <abbr title="Hypertext Markup Language">HTML</abbr></h2>
<p>
	<abbr title="Extensible Markup Language">XML</abbr>&apos;s greatest strength is that unlike <abbr title="Hypertext Markup Language">HTML</abbr>, it must be valid to be rendered.
	Rendering malformed files by default isn&apos;t the best idea.
	With <abbr title="Extensible Markup Language">XML</abbr>, when you check out how your code looks, you can immediately see when your code&apos;s malformed so you can fix it.
	In <abbr title="Hypertext Markup Language">HTML</abbr>, such errors are often glossed over by the Web browser so you don&apos;t even see them.
	Before the <abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr> formed and got involved, there was another important reason to use <abbr title="Extensible Markup Language">XML</abbr> as well: mobile clients.
	Fixing malformed markup in order to render it takes electrical power and processing power, both things that are in shorter supply on mobile clients.
	Had the Web moved forward with <abbr title="Extensible Hypertext Markup Language">XHTML</abbr>2 and <abbr title="Hypertext Markup Language">HTML</abbr> been discontinued, mobile clients wouldn&apos;t have to have been made to interpret bad markup.
	They could rely on markup to be clean, and if it wasn&apos;t, they could display the same error message that would be displayed on a desktop client.
	Thanks to the <abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr> though, <abbr title="Hypertext Markup Language">HTML</abbr> is continuing forward, despite its glaring flaws, and mobile clients will likely always spend their limited resources on cleaning up broken pages internally before rendering them.
</p>
<h2>Escape your code properly</h2>
<p>
	Please don&apos;t be a lazy bastard.
	Don&apos;t use <code>&lt;![CDATA[</code> <code>]]&gt;</code> in your code.
	There are exactly zero cases in which this construct is needed.
	All that this construct does is allow you to be lazy and neglect to escape your <code>&lt;</code>, <code>&gt;</code>, and <code>&amp;</code> characters.
	I&apos;m not entirely certain, but it&apos;s possible that it also functions in some cases in which <code>&quot;</code> or <code>&apos;</code> could need to be escaped.
	However, you should strive to write clean code.
	Simply escape your characters properly, and you won&apos;t have any issues.
	Escaping your characters properly even works within <code>&lt;script/&gt;</code> and <code>&lt;style/&gt;</code> tags; it doesn&apos;t interfere with the interpretation of JavaScript or <abbr title="Cascading Style Sheets">CSS</abbr>.
	That said, you shouldn&apos;t have JavaScript or <abbr title="Cascading Style Sheets">CSS</abbr> in the same file as your <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> in most cases.
	In all but a few corner cases, JavaScript and <abbr title="Cascading Style Sheets">CSS</abbr> should be stored in external files and linked to by the <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> file.
</p>
<h2>Criticism of <abbr title="Extensible Markup Language">XML</abbr></h2>
<p>
	Most of the criticism that I hear about <abbr title="Extensible Markup Language">XML</abbr> falls into one of three categories.
</p>
<h3><abbr title="Hypertext Markup Language">HTML</abbr> allows broken code</h3>
<p>
	It used to be that when an <abbr title="Hypertext Markup Language">HTML</abbr> page was malformed, Web browsers wouldn&apos;t be able to render it.
	This was like any other file; when it&apos;s malformed, it doesn&apos;t make any sense to the renderer.
	However, back when competition between Web browser vendors was more fierce, Web browser venders started adding the ability to render malformed markup.
	In this way, Web developers that used those Web browsers wouldn&apos;t notice mistakes in their code, so those mistakes didn&apos;t get fixed.
	Other Web browsers that hadn&apos;t yet added the ability to render malformed documents weren&apos;t able to display these pages, and users blamed the Web browsers that conformed to the standard instead of those that had caused it: the Web browsers that <strong>*didn&apos;t*</strong> conform to the standard.
	The rendering of invalid <abbr title="Hypertext Markup Language">HTML</abbr> is a horrid artifact of a past war between software developers.
	It&apos;s not a good thing, but a blemish on the entire Web.
	If you try using the <abbr title="World Wide Web Consortium">W3C</abbr> validator on most Web pages, you&apos;ll find that even those developed by the most professional of companies often aren&apos;t even valid pages.
	Being able to see your page break and know to fix it is a <strong>*very good thing*</strong>, which is a big part of why we need <abbr title="Extensible Markup Language">XML</abbr>.
</p>
<h3><abbr title="Hypertext Markup Language">HTML</abbr> allows missing tags</h3>
<p>
	Some people claim that omitting close tags is somehow cleaner because it&apos;s less verbose in some cases.
	<abbr title="Hypertext Markup Language">HTML</abbr>5 allows that practice in many cases.
	However, is that really cleaner?
	You&apos;re not telling the parser where your element stops.
	Instead, you&apos;re relying on the parser to end your element when another begins or when it finds itself unable to continue the element for some reason, such as when the container element ends.
	Omitting useful information isn&apos;t the way to write clean code.
	Leaving out closing tags is about as clean as leaving out closing parentheses.
</p>
<blockquote>
	<p>
		Does this look very clean to you?
		(It&apos;s shorter, but that doesn&apos;t make it cleaner.
	</p>
</blockquote>
<p>
	As a side note, <abbr title="Extensible Markup Language">XML</abbr> also has a neat feature in which single tags look different than open tags.
	You might not find that useful if you know all of the tags available in your markup language, but often times, you know the subset of tags that you actually use or that you use most often.
	When looking at <abbr title="Extensible Markup Language">XML</abbr>, you know when a tag you don&apos;t recognize is open or is a single tag with no close tag.
	You can even self-close empty tags.
	For example, I write <code>&lt;script src=&quot;/script/javascript.js&quot; /&gt;</code> instead of <code>&lt;script src=&quot;/script/javascript.js&quot;&gt;&lt;/script&gt;</code>.
	In <abbr title="Hypertext Markup Language">HTML</abbr>, there&apos;s no way to condense this, and you must always specify a close tag even when it makes no sense for the element to even be open.
	Otherwise, the entire rest of the page might be interpreted as malformed JavaScript instead of as <abbr title="Hypertext Markup Language">HTML</abbr>.
</p>
<h3><abbr title="JavaScript Object Notation">JSON</abbr> (or something else) is better for storing data</h3>
<p>
	<abbr title="Extensible Markup Language">XML</abbr> isn&apos;t a data-storage format.
	It&apos;s a document markup format. It&apos;s Extensible Markup Language, after all, not Extensible Data-Storage Language.
	If you misuse a tool, sure, you&apos;ll get poor performance out of it.
	For example, if you store textual information as a <abbr title="Portable Network Graphic">PNG</abbr> file and claim that that&apos;s what <abbr title="Portable Network Graphic">PNG</abbr> files are for, it&apos;s going to make the <abbr title="Portable Network Graphic">PNG</abbr> format look bad.
	<abbr title="Portable Network Graphic">PNG</abbr> files are absolutely horrid for storing textual information.
	However, they excel at storing non-photographic graphic art.
	The same applies to <abbr title="Extensible Markup Language">XML</abbr>.
	If you try to use <abbr title="Extensible Markup Language">XML</abbr> as a data-storage format, you&apos;re going to get suboptimal results.
	If you&apos;re storing data, yes, <abbr title="JavaScript Object Notation">JSON</abbr> is the better format!
	However, it&apos;s not because <abbr title="JavaScript Object Notation">JSON</abbr> is actually a better format than <abbr title="Extensible Markup Language">XML</abbr> at all.
	It&apos;s because <abbr title="JavaScript Object Notation">JSON</abbr>&apos;s strength is data storage while <abbr title="Extensible Markup Language">XML</abbr>&apos;s strength is instead document markup.
</p>
<h4><abbr title="Extensible Markup Language">XML</abbr> for data storage</h4>
<p>
	As I said, <abbr title="Extensible Markup Language">XML</abbr> is a markup language, not a data-storage language.
	However, it can still be used effectively for data storage when used correctly.
	Much of the problem when developing an <abbr title="Extensible Markup Language">XML</abbr> flavor for data storage that makes it inefficient is caused by people doing it wrong.
	Again, this isn&apos;t the fault of <abbr title="Extensible Markup Language">XML</abbr> and doesn&apos;t mean that <abbr title="Extensible Markup Language">XML</abbr> itself isn&apos;t good for what it&apos;s good at.
	Instead of having an element for each key/value pair, it&apos;s often more efficient to instead use attributes of a single element.
	According to Wikipedia, doing that <a href="https://en.wikipedia.org./wiki/JSON#XML">results in file sizes that are just as small or only slightly larger than those achieved in <abbr title="JavaScript Object Notation">JSON</abbr></a>.
	Even when <abbr title="Extensible Markup Language">XML</abbr> is the wrong tool for the job, it does pretty well when used with a little skill.
	Now that&apos;s impressive!
	Additionally, in <abbr title="Extensible Markup Language">XML</abbr>, you can see what element is ending when it ends.
	In <abbr title="JavaScript Object Notation">JSON</abbr>, you can&apos;t do that.
	Instead, you have to count your layered braces to find the start of the nested element to know what element it is.
	Proper indention of course helps with this, but it helps in <abbr title="Extensible Markup Language">XML</abbr> too.
</p>
		<hr/>
		<p>
			Copyright © 2017 Alex Yst;
			You may modify and/or redistribute this document under the terms of the <a rel="license" href="/license/gpl-3.0-standalone.xhtml"><abbr title="GNU&apos;s Not Unix">GNU</abbr> <abbr title="General Public License version Three or later">GPLv3+</abbr></a>.
			If for some reason you would prefer to modify and/or distribute this document under other free copyleft terms, please ask me via email.
			My address is in the source comments near the top of this document.
			This license also applies to embedded content such as images.
			For more information on that, see <a href="/en/a/licensing.xhtml">licensing</a>.
		</p>
		<p>
			<abbr title="World Wide Web Consortium">W3C</abbr> standards are important.
			This document conforms to the <a href="https://validator.w3.org./nu/?doc=https%3A%2F%2Fy.st.%2Fen%2Fopinion%2FXML.xhtml"><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> 5.1</a> specification and uses style sheets that conform to the <a href="http://jigsaw.w3.org./css-validator/validator?uri=https%3A%2F%2Fy.st.%2Fen%2Fopinion%2FXML.xhtml"><abbr title="Cascading Style Sheets">CSS</abbr>3</a> specification.
		</p>
	</body>
</html>