<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Technology of Content &#187; html</title>
	<atom:link href="http://blog.technologyofcontent.com/tag/html/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.technologyofcontent.com</link>
	<description>Ramblings on the technology of content management</description>
	<lastBuildDate>Sun, 25 Apr 2010 21:45:47 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Content microarchitecture: How I learned to love HTML part 2</title>
		<link>http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/</link>
		<comments>http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/#comments</comments>
		<pubDate>Sun, 15 Nov 2009 16:34:24 +0000</pubDate>
		<dc:creator>justin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[CMS]]></category>
		<category><![CDATA[html]]></category>

		<guid isPermaLink="false">http://blog.technologyofcontent.com/?p=145</guid>
		<description><![CDATA[I posted recently on an unfinished series by Daniel Jacobson, which was perhaps slightly unfair, so I thought I should write a followup to his final part.

My argument was mainly that storing flat, unstructured data was not enough for most content projects, and the difficult questions of structure needed to be addressed. Daniel&#8217;s third part [...]]]></description>
			<content:encoded><![CDATA[<p>I <a href="http://blog.technologyofcontent.com/2009/11/id-love-to-stay-here-and-be-normal-but-its-just-so-overrated-or-how-i-learned-to-stop-worrying-and-love-html/">posted recently</a> on an unfinished series by Daniel Jacobson, which was perhaps slightly unfair, so I thought I should write a followup to <a href="http://blog.programmableweb.com/2009/11/11/content-portability-building-an-api-is-not-enough/">his final part</a>.</p>

<p>My argument was mainly that storing flat, unstructured data was not enough for most content projects, and the difficult questions of structure needed to be addressed. Daniel&#8217;s third part addresses how they do this. Actually when I first looked through the NPR content after reading the first two articles I could not find any content that had inline HTML, clearly was an accident should have read more, as it is used.</p>

<p>The actual NPR process is interesting. In particular it shows the amount of care and attention in curating content that is needed to keep it reusable, repurposable and valuable. Semantic content requires you understand the range of meanings that it encodes and how to work with them, and transform them, and quality control them. And that means you need to know every tag and attribute that is going into the system and what that means for every output you are or may using.</p>

<p>One of the outputs that many people forget is plain text, and NPR is very clear on the writing style that is necessary for writing for HTML and plain text. Everything must make sense in the text form; links should be additional information that adds to the text not necessary to understand it. And of course no &#8220;click here&#8221;. Text output for other devices may vary between the expressiveness of HTML and that of plain text. Text that reads sanely also helps screen readers and other assistive technologies make the content understandable.</p>

<p>The key points here are that content markup must be</p>

<ol>
<li>Valid. Processing is likely to be inaccurate without valid content, and tools will be more limited in how the process it, or will fail unexpectedly. Best fix this at the beginning of the pipeline.</li>
<li>Meaningful. You need the markup to mean what the author intended, so look at interface usability and training.</li>
<li>Accepted. You do not have to accept all valid XHTML, say. For a start, XML is an extensible language! You can choose a whole range of markup for a story, from the very minimal, to marking up each person and place involved, or more.</li>
<li>Stored. The marked up text must be stored; the NPR decomposition is plain text plus plus normalized markup which may work for some systems; storing marked up HTML without output transforms may work out better for others.</li>
<li>Processed. You need to handle each kind of markup for all output mechanisms, so they need to be introduced in a controlled way, although this should not be difficult. Changing markup is something that may need to happen.</li>
</ol>

<p>I think the third part is the interesting one. Information architecture with websites often stops at the content level, missing out on this information microarchitecture of the textual content itself, leaving this to authors without enough guidance to build a consistent structure to maximise the long term content value.</p>

<p><a href="http://www.teara.govt.nz/en/fossils/7/1"><img src="http://www.teara.govt.nz/files/p9047niwa.jpg" alt="Fossil foraminifera" width="100%"></a></p>
]]></content:encoded>
			<wfw:commentRss>http://blog.technologyofcontent.com/2009/11/content-microarchitecture-how-i-learned-to-love-html-part-2/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>
