y.st.
/
https


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118
							<?xml version="1.0" encoding="utf-8"?>
<!--
	<https://y.st./>
	Copyright © 2022 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 <http://www.gnu.org./licenses/>.
-->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>Yst Domain</title>
		<meta name="viewport" content="width=device-width" />
	</head>
	<body>
		<h1>Yst Domain</h1>
		<h2>Website state</h2>
		<p>
			A while back, I deleted my entire website for privacy reasons.
			I greatly miss having a website though, so I&apos;m setting up a new one now with less-personal pages.
			For now, I don&apos;t really have much content or a useful homepage.
			I&apos;ll get to setting up a homepage once I know what to put on it.
			For now, just status website status reports, I guess!
		</p>
		<h2><abbr title="Extensible Markup Language">XML</abbr> studies</h2>
		<p>
			After writing the section below, I got to work reading various <abbr title="Uniform Resource Indicator">URI</abbr>-related <abbr title="Request for Comments">RFC</abbr>s.
			However, I soon realised that I had a more-urgent issue: I was writing all my pages directly as <abbr title="Extensible HyperText Markup Language">XHTML</abbr>, rather than use any sort of template mechanism.
			This is fine for now, but the more pages I add, the more difficult it will be to maintain their navigation links and the more difficult it will be to update all the pages to add a templating mechanism later.
			This is something I really ought to be focussing on sooner rather than later.
		</p>
		<p>
			My previous website worked by separating content from templates, but with both being written in and containing programming code.
			This time, I really want to separate the programming code out as well, leaving the content and the templates as stand-alone files that don&apos;t eventually get gunked up with years worth of strange programming quirks that have built up from all the one-off situations I&apos;ve had to write into various sections of the website.
			I just want something clean that can withstand the test of time, where if I go through and try to do a code clean-up, I&apos;m not wading through my content and templates to do so.
		</p>
		<p>
			I started out by figuring out which characters I felt comfortable designating as special characters to use in my templating language, then used some of them to draft the beginnings of a sort of tagging language.
			But then, I got to the part where I needed to define the language for the content files, so it&apos;d be known what needed to be inserted where in the template.
			I ended up deciding to just use <abbr title="Extensible Markup Language">XML</abbr>.
			But if I&apos;m using <abbr title="Extensible Markup Language">XML</abbr> for the content, why should I not use <abbr title="Extensible Markup Language">XML</abbr> for the templates as well?
			And on top of that, I&apos;ll be pretty much making up <abbr title="Extensible Markup Language">XML</abbr> tags.
			Do I need an <abbr title="Extensible Markup Language">XML</abbr> namespace for that?
			And what about a <abbr title="document type definition">DTD</abbr>?
			Are <abbr title="Extensible Markup Language">XML</abbr> namespaces dependent on <abbr title="document type definition">DTD</abbr>s in any way (or vice versa), or are they unrelated?
			I just don&apos;t know.
			I&apos;ve never actually done custom stuff like this.
			I&apos;ve only ever used existing <abbr title="Extensible Markup Language">XML</abbr> document types.
		</p>
		<p>
			So anyway, before I move on with my Minetest work, I want to learn more about <abbr title="Uniform Resource Indicator">URI</abbr>s.
			Before I do mush studying on that front, I want to get my home on the Web rebuilt.
			Rebuilding my home on the Web with a proper foundation is going to require me to focus on <abbr title="Extensible Markup Language">XML</abbr> namespaces and <abbr title="document type definition">DTD</abbr>s for a bit.
			I&apos;m, like, three layers deep in the stack.
		</p>
		<h2><abbr title="Uniform Resource Indicator">URI</abbr> scheme research</h2>
		<p>
			Working with <abbr title="Uniform Resource Indicator">URI</abbr>s has been a hobby of mine for years, now.
			My previous website had several pages I&apos;d written about various <abbr title="Uniform Resource Indicator">URI</abbr>-related topics, and I&apos;ll very likely put those back up on this new website once I get to that point in my new readings.
			For now though, I want to do some more research and learn about various <abbr title="Uniform Resource Indicator">URI</abbr> specifications.
			I&apos;ll be starting with <abbr title="Uniform Resource Indicator">URI</abbr> schemes.
			My first task will be to sort all the <a href="https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml">registered schemes</a> into categories:
		</p>
		<ul>
			<li>
				Schemes that sometimes or always rely on <abbr title="Domain Name System">DNS</abbr>, allowing for distributed minting of <abbr title="Uniform Resource Indicator">URI</abbr>s rather than relying on a monopoly-holder to control the service for the entire <abbr title="Uniform Resource Indicator">URI</abbr> scheme (example: <code>https:</code>)
			</li>
			<li>
				Schemes that don&apos;t designate remote resources (example: <code>data:</code>)
			</li>
			<li>
				Schemes that designate a remote resource, but that the remote resource is ambiguous and depends on the user&apos;s configuration (example: <code>apt:</code>)
			</li>
			<li>
				Schemes that define illegal syntax (example: <code>aaas:</code>)
			</li>
			<li>
				Schemes that imply a particular service provider (example: <code>aim:</code>)
			</li>
		</ul>
		<p>
			Once I know more about all the schemes, I can decide where I want to focus my attention next.
			Specifically, schemes that imply a particular service provider are useless to me, as they&apos;re typically under the control of some shady service provider that requires untrustworthy software be installed on your machine, which isn&apos;t safe.
			Even when no proprietary software is needed, you&apos;re still at the mercy of the whims of the service provider, who could - for example - decide to permanently discontinue the service and render all <abbr title="Uniform Resource Indicator">URI</abbr>s that use the scheme obsolete in the blink of an eye.
			Without an open platform, knowledge on such <abbr title="Uniform Resource Indicator">URI</abbr>s isn&apos;t useful in the long run.
			Schemes with illegal syntax are interesting due to their paradoxical and rare nature, but after having compiles a list of them and given a brief description of each, I doubt there will be much else to research and learn about them.
			Next, schemes that depend on user settings are interesting, but of little practical value.
			They&apos;re still fun to play with, though.
			Schemes that don&apos;t designate remote resources also will likely be interesting but quickly lead to a point in which there&apos;s little left to discover.
			<abbr title="Domain Name System">DNS</abbr>-enabled schemes have a number of other quirks to take a look at, though.
			Though I&apos;ve specifically referred to <abbr title="Domain Name System">DNS</abbr>, many of these schemes will take other sorts of hostnames too, so we can take a look at special <abbr title="Internet Protocol">IP</abbr> addresses and special sections of the <abbr title="Domain Name System">DNS</abbr> name space, for example.
			I&apos;ve also recently learned about the existence of the <a href="https://www.rfc-editor.org/rfc/rfc8615.html"><code>/.well-known/</code></a> path prefix used by some <abbr title="Uniform Resource Indicator">URI</abbr> schemes.
			That could be a fun place to poke around as well.
		</p>
		<h2>Minetest</h2>
		<p>
			I was working on some <a href="https://www.minetest.net/">Minetest</a> mods in preparation for a let&apos;s play series I was hoping to start, but I&apos;ve really lost my energy on that for the time being.
			I was hoping to get the first alpha release of the main mod for the series completed by the end of the year (2022, at the time of writing this), but have decided to put that aside and just accept that it&apos;s not happening.
			I&apos;ve been working on this mod in many forms over the past few years.
			Each time, I end up hitting a roadblock, being unable to progress, then throwing out everything I&apos;ve done so far.
			Later, I tweak the idea a bit, and start over from scratch.
			This time, I really think it&apos;s different.
			I think this iteration is going to work out very well, and I&apos;ve gotten much further in development than in any of the past attempts.
			I just legitimately don&apos;t have the energy to keep going on the project right now, so I&apos;m taking a break and rebuilding my website and focussing on <abbr title="Uniform Resource Indicator">URI</abbr> research instead.
		</p>
	</body>
</html>