Notice how bad, as of this writing, the typography is on this page.

Use this as an example of the weirdness of the difference in creator agency and consumer expectations about presentation of the written word when it comes to print vs Web.

There is, actually. Look at Google Docs, Office 365, etc. Those are all an end-run around the fact that webdevs are self-serving and haven't prioritized making desktop publishing for casual users a priority.

The webdev industry subverts users' ability to publish to the Web natively, and Google, MS et al subvert native Web features in order to capture users.

The users are there.

... which may have really happened, per se, but it didn't wholly incorporate (subsume/cannibalize) conventional desktop publishing, which is still in 2023 dominated by office suites (a la MS Word) or (perversely) browser-based facsimiles like Google Docs. Because the Web as it came to be used turned out to be as a sui generis medium, not exactly what TBL was aiming for, which was giving everything (everything—including every existing thing) its own URL.

The solution is to not create keep creating these fucking problems in the first place.

A big problem with what's in this paper is that its logical paths reflect the déformation professionnelle of its author and the technologists' milieu.

Links are Works Cited entries. Works Cited entries don't "break"; the works at the other end don't "change".

See also:

Google Docs is one of the best ways to make content to put on the Web.

https://crussell.ichi.city/food/inauguration/

It's my contention that this is a matter of people misusing the URL (and the Web, generally); Web pages should not be expected to "update" any more than you expect the pages of a book or magazine or a journal article to be self-updating.

We have taken the original vision of the Web -- an elaborately cross-referenced information space whose references can be mechanically dereferenced -- and rather than treating the material as imbued with a more convenient digital access method and keeping in place the well-understood practices surrounding printed copies, we compromised the entire project by treating it as a sui generis medium. This was a huge mistake.

This can be solved by re-centering our conception of what URLs really are: citations. The resources on the other sides of a list of citations should not change. To the extent that anything ever does appear to change, it happens in the form of new editions. When new editions come out, nobody goes around snapping up the old copies and replacing it for no charge with the most recent one while holding the older copies hostage for a price (or completely inaccessible no matter the price).

This is a very useful but underutilized property. It allows you to e.g. announce in advance that a resource will exist at some point in the future, and thereby effectively receive "updates" to the linking document without requiring changes to the document itself.

Another good jumping off point for why document mutability should be considered harmful. https://hypothes.is/a/N_gPAAmQEe6kvXNEm10s7w

I'll go further and say that, wrt the original goals of the Web—and the principles we should continue to strive for today, despite widespread practice otherwise—Modification (should be) Considered Harmful.

Git has the right idea. Hypermedia collections should also be append-only (not different resources masquerading under the same name).

The Web does not yet meet its design goal as being a pool of knowledge that is as easy to update as to read. That level of immediacy of knowledge sharing waits for easy-to-use hypertext editors to be generally available on most platforms. Most information has in fact passed through publishers or system managers of one sort or another.

The common perception of the Web as a sui generis medium is also harmful. Conceptually, the most applicable relevant standard for Web content are just the classic standards of written works, generally. But because it's embodied in a computer people end up applying the standards of have in mind for e.g. apps.

You check out a book from the library. You read it and have a conversation about it. Your conversation partner later asks you to tell them the name of the book, so you do. Then they go to the library and try to check it out, but the book they find under that name has completely different content from what you read.

This brings interesting questions back up like what happens to your online "presence" after you die (for lack of a better turn of phrase)?

Aaron Swartz famously left instructions predating (by years IIRC) the decision that ended his life for the way that unpublished and in-progress works should be licensed and who should become stewards/executors for the personal infrastructure he managed.

The chrisseaton.com landing page has three social networking CTAs ("Email me", etc.) Eventually, the chrisseaton.com domain will lapse, I imagine, and the registrar or someone else will snap it up to squat it, as is their wont. And while in theory chrisseaton.github.io will retain all the same potential it had last week for much longer, no one will be able to effect any changes in the absence of an overseer empowered to act.

So make your application document-driven (i.e. actually RESTful).

It's interesting that we have Web forms and that we call them that and yet very few people seem to have grokked the significance of the term and connected it to, you know, actual forms—that you fill out on paper and hand over to someone to process, etc. The "application" lies in that latter part—the process; it is not the visual representation of any on-screen controls. So start with something like that, and then build a specialized user agent for it if you can (and if you want to). If you find that you can't? No big deal! It's not what the Web was meant for.

So don't.

@1:10:20

With HTML you have, broadly speaking, an experience and you have content and CSS and a browser and a server and it all comes together at a particular moment in time, and the end user sitting at a desktop or holding their phone they get to see something. That includes dynamic content, or an ad was served, or whatever it is—it's an experience. PDF on the otherhand is a record. It persists, and I can share it with you. I can deliver it to you [...]

NB: I agree with the distinction being made here, but I disagree that the former description is inherent to HTML. It's not inherent to anything, really, so much as it is emergent—the result of people acting as if they're dealing in live systems when they shouldn't.

This is a massive failure of infrastructure (and education/"professionalism"—by and large, most people whose careers are in operating or maintaining Web infrastructure don't haven't been inculcated into or adopted the sort of "code of ethics" that sees this as a failure).

The thing might just be for something like the Internet Archive to get into training or selling professional services for handling companies' "Web presence, done the right way". (This is def. take some organizational restructuring, however.) I'd like to see, for example, IA-certified partner organizations that uphold the principles described here and the original vision for the Web, and professional associations that work hard at making sure the status quo improves a lot over what's common today (and doesn't slide back).

I can't get behind the call to anger here, even if I don't approve of Apple's stance on being the gatekeeper for the software that runs on your phone.

Elsewhere (in the comments by the author on HN), he or she writes:

The biggest problem I try to convey is that you have no way of knowing you'll get the rejection

No, I think there were pretty good odds that before even submitting the first iteration it would have been rejected, based purely on the concept alone. This is not an app. It's a set of pages—only implemented with the iOS SDK (and without any of the affordances, therefore, that you'd get if you were visiting in a Web browser. For whatever reason, the author both thought this was a good idea and didn't review the App Store guidelines and decided to proceed anyway.

Then comes the part where Apple sends the rejection and tells the author that it's no different from a Web page and doesn't belong on the App Store.

Here's where the problem lies: at the point where you're - getting rejections, and then - trying to add arbitrary complexity to the non-app for no reason other than to try to get around the rejection

... that's the point where you know you're wasting your time, if it wasn't already clear before—and, once again, it should have been. This is a series of Web pages. It belongs on the Web. (Or dumped into a ZIP and passed around via email.) It is not an app.

The author in the same HN comment says to another user:

So you, like me, wasted probably days (if not weeks) to create a fully functional app, spent much of that time on user-facing functions that you would have probably not needed

In other words, the author is solely responsible for wasting his or her own time.

To top it off, they finish their HN comment with this lament:

It's not like on Android where you can just share an APK with your friends.

Yeah. Know what else allows you to "just" share your work...? (No APK required, even!)

Suppose you were taking classes and wanted to know the rubric and midterm schedule. Only rather than pointing you to the appropriate course Web page or sharing a PDF or Word document with that information, the professor tells you to download an executable which you are expected to run on your computer and which will paint that information on the screen. You (and everyone else) would hate them—and you wouldn't be wrong to.

I'm actually baffled why an experienced iOS developer is surprised by any of the events that unfolded here.

That's a pretty deficient workaround, given the obvious downsides. A more robust workaround would be to make the cart stateless, as far as the server is concerned, for non-logged-in users; don't depend on cookies. A page request instead amounts to a request for the form that has this and this and this pre-selected ("in the cart"). Like with paper.

There's a lot to be gained by reflecting on pre-Web paradigms and hewing to similar approaches—electing to be bound by the constraints. Print is a discipline, and the practices surrounding the print-based publishing industry comprises a form of technology itself.

Related: lineality is a virtue.

Imagine if this were just the format that the source document itself used...

It's worth introspecting on why any given person might hesitate to feel that they can commit. This is almost always comes down to "maintainability"—websites are, like many computer-based endeavors, thought of as projects that have to be maintained. This is a failure of the native Web formats to appreciably make inroads as a viable alternative to traditional document formats like PDF and Word's .doc/.docx (or even the ODF black sheep). Many people involved with Web tech have difficulty themselves conceptualizing Web documents in these terms, which is unfortunate.

If you can be confident that you can, today, bang out something in LibreOffice, optionally export to PDF, and then dump the result at a stable URL, then you should feel similarly confident about HTML. Too many people have mental guardrails preventing them from grappling with the relevant tech in this way.

This is where I think Glitch goes wrong. Why such a focus on apps (and esp. pushing the same practices and overcomplicated architecture as people on GitHub trying to emulate the trendiest devops shovelware)?

"Web" is a red herring here. Make the Web more accessible for app creation, sure, but what about making it more accessible (and therefore simpler) for sharing simple stuff (like documents comprising the written word), too? Glitch doesn't do well at this at all. It feels less like a place for the uninitiated and more like a place for the cool kids who are already slinging/pushing Modern Best Practices hang out—not unlike societal elites who feign to tether themself to the mast of helping the downtrodden but really use the whole charade as machine for converting attention into prestige and personal wealth. Their prices, for example, reflect that. Where's the "give us, like 20 bucks a year and we'll give you better alternative to emailing Microsoft Office documents around (that isn't Google Sheets)" plan?

I dunno. I think all the things about dynamism and liveness that follow this claim are true in the minds of most people. The rarity is for people to conceive of content on the Web (or elsewhere rendered to a computer screen) as capable of being imbued with the fixity of print. Everything feels transient and rests on a shaky, fleeting foundation..

It actually can be easier than that if the only reason PHP is involved is for templating and you don't want CGI. (NB: This is admittedly contra "the mildly dynamic website" described in the article).

If you're Alice of alice.example.com, then you open up your local copy of e.g. https://alice.example.com/sop/pub.app.htm, proceed to start "hacking on it until it works", then rsync the output.

No, but further: the question (about being "limited") presupposes something that isn't true.

If you're doing PHP here, you're doing it wrong—unless the PHP application is written with great care (i.e. unidiomatically) and has some way to reveal its own program text (as first-class content). Otherwise, that's a complete failure to avoid the "elsewhere"-ness that we're trying to eradicate.

Answer: it's hosted under the same auspices as the main content. The "editor" is first-class content (in the vein of ANPD); it's really just another document describing detailed procedures for how the site gets updated.

That makes them constitute separate editions. It makes things messy.

My argument for the use of the Web as a medium for publishing the procedures by which the documents from a given authority are themselves published shares something in common with the argument for exploiting Lisp's homoiconicity to represent a program as a data structure that is expressed like any other list.

There are traces here as well from the influence of the von Neumann computational model, where programs and data are not "typed" such that they belong to different "classes" of storage—they are one and the same.

This is less than ideal. Besides non-technical people needing to wade into the middle of (what very well might appear to them to be a blob of) JS to update their site, here are some things that Zonelets depends on JS for:

1. The entire contents of the post archives page
2. The footer
3. The page title

This has real consequences for e.g. the archivability for a Zonelets site.

The JS-editing problem itself could be partially ameliorated by with something like the polyglot trick used on flems.io and/or the way triple scripts do runtime feature detection using shunting. When the script is sourced via script element from another page, it behaves as JS, but when visited directly as the browser destination it is treated like HTML and has its own DOM tree for the script itself to make the necessary modifications easier. Instead of requiring the user to edit it as freeform text, provide a structured editing interface, so e.g. adding a new post is as simple as clicking the synthesized "+" button in the list of posts, copying the URL of the post in question, and then pasting it in—to a form field. The Zonelets script itself should take care of munging it into the appropriate format upon form "submission". It can also, right there, take care of the escaping issue described in the FAQ—allow the user to preview the generated post title and fix it up if need be.

Additionally, the archives page need not by dynamically generated by the client—or rather, it can be dynamically filled in exactly once per update—on the author's machine, and then be reified into static HTML, with the user being instructed to save it and overwrite the served version. This gets too unwieldy for next/prev links in the footer, but (a) those are non-essential, and don't even get displayed for no-JS users right now, anyway; and (b) can be seen to violate the entire "UNPROFESSIONAL" etthos.

Alternatively, the entire editing experience can be complimented with bookmarklets.

NB: This piece has been through many revisions (or, rather, many different pieces have been published with this identifier).

Check it out with the Wayback Machine: https://web.archive.org/web/*/http://akkartik.name/about

This appeal would have a greater effect if it weren't itself published in a format that exhibits so much of what was less desirable of the pre-modern Web—fixed layouts that show no concern for how I'm viewing this page and causes horizontal scrollbars, overly stylized MySpace-ish presentation, and a general imposition of the author's preferences and affinity for kitsch above all else—all things that we don't want.

I say this as someone who is not a fan of the trends in the modern Web. Responsive layouts and legible typography are not casualties of the modern Web, however. Rather, they exhibit the best parts of its maturation. If we can move the Web out of adolescence and get rid of the troublesome aspects, we'd be doing pretty good.

There's way too much excuse-making in this post.

They're books. If there's any defensible* reason for making the technical decision to go with "inert" media, then a bunch of books has to be it.

* Even this framing is wrong. There's a clear and obvious impedance mismatch between the Web platform as designed and the junk that people squirt down the tubes at people. If there's anyone who should be coming up with excuses to justify what they're doing, that burden should rest upon the people perverting the vision of the Web and treating it unlike the way it's supposed to be used—not folks like acabal and amitp who are doing the right thing...

(NB: RWI — Real World Interpretation)

But maybe you don't need to do that. Maybe it would be instructive to take lessons from the traditional (pre-digital) publishing industry and consider how things like "print runs" and "reissues" factored in.

If you write a blog post in 2017 and the page is acceptable*, and then five years later you're publishing a new post today in 2022 under new design norms and trying to retrofit that design onto your content from 2017, then that sounds a lot like a reprint. If that makes sense and you want to go ahead and do that, then fair enough, but perhaps first consider whether it does make sense. Again, that's what you're doing—every time you go for a visual refresh, it's akin to doing a new run for your entire corpus. In the print industry (even the glossy ones where striking a chord visually was and is something considered to merit a lot of attention), publishers didn't run around snapping up old copies and replacing them with new ones. "The Web is different", you might say, but is it? Perhaps the friction experienced here—involved with the purported need to pick up a static site generator and set your content consistently with templates—is actually the result of fighting against the natural state of even the digital medium?

* ... and if you wrote a blog post in 2017 and the page is not acceptable now in 2022, maybe it's worth considering whether it was ever really acceptable—and whether the design decisions you're making in 2022 will prove to be similarly unacceptable in time (and whether you should just figure out the thing where that wouldn't be the case, and instead start doing that immediately).

This is a common enough feeling (not about Publii, specifically; just the general concern for flexibility and control in static site generators), but when you pull back and think in terms of normalcy and import, it's another example of how most of what you read on the internet is written by insane people.

Almost no one submitting a paper for an assignment or to a conference cares about styling the way that the users of static site generators (or other web content publishing pipelines) do. Almost no one sending an email worries about that sort of thing, either. (The people sending emails who do care a lot about it are usually doing email campaigns, and not normal people carrying out normal correspondence.) No one publishing a comment in the thread here—or a comment or post to Reddit—cares about these things like this, nor does anyone care as much when they're posting on Facebook.

Somehow, though, when it comes to personal Web sites, including blogs, it's MySpace all over again. Visual accoutrement gets pushed to the foreground, with emphasis on the form of expression itself, often with little relative care for the actual content (e.g. whether they're actually expressing anything interesting, or whether they're being held back from expressing something worthwhile by these meta-concerns that wouldn't even register if happening over a different medium).

When it comes to the Web, most instances of concern for the visual aesthetic of one's own work are distractions. It might even be prudent to consider those concerns to be a trap.

Yeah, but...

Keeping your website's look 'up to date' requires changes, but keeping your website up does not require "keeping its look 'up to date'".

The problem almost certainly starts with the conception of what we're doing as "building websites".

When we do so, we mindset of working on systems

If your systems work compromises the artifacts then it's not good work

This is part of a broader phenomenon, which is that when computers are involved with absolutely anything people seem to lose their minds good sensibilities just go out the window

low expectations from everyone everyone is so used to excusing bad work

sui generis medium

violates the principle of least power

what we should be doing when grappling with the online publishing problem—which is what this is; that's all it is—is, instead of thinking in terms of working on systems, thinking about this stuff in such a way that we never lose sight of the basics; the thing that we aspire to do when we want to put together a website is to deal in

documents and their issuing authority

That is, a piece of content and its name (the name is a qualified name that we recognize as valid only when the publisher has the relevant authority for that name, determined by its prefix; URLs)

that's it that's all a Web site is

anything else is auxiliary

really not a lot different from what goes on when you publish a book take a manuscript through final revisions for publication and then get an ISBN issued for it

so the problem comes from the industry

people "building websites" like politicians doing bad work and then their constituents not holding them accountable because that's not how politics works you don't get held accountable for doing bad work

so the thing to do is to recognize that if we're thinking about "websites" from any other position things that technical people try to steer us in the direction of like selecting a particular system and then propping it up and how to interact with a given system to convince it to do the thing we want it to do— then we're doing it wrong

we're creating content and then giving it a name

Desired workflow:

1. I navigate to the APL login page https://austin.bibliocommons.com/user/login
2. I invoke a bookmarklet on the login page that opens a new browser window/tab
3. In the second tab, I navigate here—to a locally saved copy of (a facsimile of) my library card
4. I invoke a bookmarklet on my library card to send the relevant details to the APL login page using window.postMessage
5. The bookmarklet set up in step 2 receives the details, fills in the login form, and automatically "garbage collects" the second tab

Some other thoughts: We can maintain a personal watchlist/readlist similarly. This document (patron ID "page") itself is probably not a good place for this. It is, however, a good place to reproduce a convenient copy of the necessary bookmarklets. (With this design, only one browser-managed bookmarklet would be necessary; with both bookmarklets being part of the document contents, the second bookmarklet used for step 4 can just be invoked directly from the page itself—no need to follow through on actually bookmarking it.)

The subtext here is, "that's why i created BeachfrontDigital". But this shows how "apps" (and systems) have poisoned how we conceptualize problems and their solutions.

The simplest solution to the problem described is a document, not a never-finished/never-production-ready app. Bespoke apps have lots of cost overhead. Documents, on the other hand—even documents with rich structure—are cheap.

I've noted elsewhere that despite the reputation of WYSIWYG editors' tendencies for handling HTML, modern mainstream Web development practices are so bad today that just typing a bunch of junk into LibreOffice and saving as HTML results in one of the most economical ways to do painless authoring of Web content...

Around 1:48:00

What if every library that you use had, like, some interactive documentation or interactive representation? [...] The author could maybe add annotations.

This is how I feel about most people's personal websites. Few people have homepages these days, but even for people who do, even fewer of those homes have anyone really living there. All their interesting stuff is going on on Twitter, GitHub, comments on message boards...

Really weird when this manifests as a bunch of people having really strong opinions about static site tech stacks and justifications for frontend tech that in practice they never use, because the content from any one of their profiles on the mainstream social networks outstrips their "home" page 100x to 1.

Funnily enough, I've been on an intellectual bent in the other direction: that we've poisoned our thinking in terms of systems, for the worse. This shows up when trying to communicate about the Web, for example.

It's surprisingly difficult to get anyone to conceive of the Web as a medium suited for anything except the "live" behavior exhibited by the systems typically encountered today. (Essentially, thin clients in the form of single-page apps that are useless without a host on the other end for servicing data and computation requests.) The belief/expectation that content providers should be given a pass for producing brittle collections of content that should be considered merely transitory in nature just leads to even more abuse of the medium.

Even actual programs get put into a ruddy state by this sort of thinking. Often, I don't even care about the program itself, so much as I care about the process it's applying, but maintainers make this effectively inextricable from the implementation details of the program itself (what OS version by which vendor does it target, etc.)

interesting taxonomy; useful for communicating about a concerted effort towards a more document-oriented correction to the modern Web?

Perversely, the author starts off getting this part wrong!

The correct answer here is to adopt the same mindset used for print, which is to say, "just don't worry about it; the value of doing so is oversold". If a print org changed their layout sometime between 1995 and 2005, did they issue a recall for all extant copies and then run around trying to replace them with ones consistent with the new "visual refresh"? If an error is noticed in print, it's handled by correcting it and issuing another edition.

As Tschichold says of the form of the book (in The Form of the Book):

The work of a book designer differs essentially from that of a graphic artist. While the latter is constantly searching for new means of expression, driven at the very least by his desire for a "personal style", a book designer has to be the loyal and tactful servant of the written word. It is his job to create a manner of presentation whose form neither overshadows nor patronizes the content [... whereas] work of the graphic artist must correspond to the needs of the day

The fact that people publishing to the web regularly do otherwise—and are expected to do otherwise—is a social problem that has nothing to do with the Web standards themselves. In fact, it has been widely lamented for a long time that with the figurative death of HTML frames, you can no longer update something in one place and have it spread to the entire experience using plain ol' HTML without resorting to a templating engine. It's only recently (with Web Components, etc.) that this has begun to change. (You can update the style and achieve consistency on a static site without the use of a static site generator—where every asset can be handcrafted, without a templating engine.) But it shouldn't need to change; the fixity is a strength.

As Tschichold goes on to say of the "perfect" design of the book, "methods and rules upon which it is impossible to improve have been developed over centuries". Creators publishing on the web would do well to observe, understand, and work similarly.

Perhaps it's not possible. (Probably not, even.) It would be very much possible to build a web browser capable of handling this page, on the other hand, and to do so in a way that produces an appreciable result in 10 minutes of hacking around with the lowliest of programming facilities: text editor macros—that is, if only it had actually been published as a webpage. Is it possible to do the same for if not just this PDF but others, too? No.

Like the parent comment by derefr, my actual, non-hypothetical practice is saving to the Wayback Machine. Right now I'm probably saving things at a rate of half a dozen a day. For those who are paranoid and/or need offline availability, there's Zotero https://www.zotero.org. Zotero uses Gildas's SingleFile for taking snapshots of web pages, not PDF. As it turns out, Zotero is pretty useful for stowing and tracking any PDFs that you need to file away, too, for documents that are originally produced in that format. But there's no need to (clumsily) shoehorn webpages into that paradigm.

If you do the print-to-PDF workflow outlined earlier in the thread, you'll realize it doesn't scale well, requiring too much manual intervention and discipline (including taking care to make sure it's filed correctly; hopefully you remember the ad hoc system you thought up last time you saved something), that it's destructive, and that it ultimately gives you an opaque blob. SingleFile-powered Zotero mostly solves all of this, and it does it in a way that's accessible in one or two clicks, depending on your setup. If you ever actually need a PDF, you can of course go back to your saved copy and produce a PDF on-demand, but it doesn't follow that you should archive the original source material in that format.

My only reservation is that there is no inverse to the SingleFile mangling function, AFAIK. For archival reasons, it would be nice to be able to perfectly reconstruct the original, pre-mangled resources, perhaps by storing some metadata in the file that details the exact transformations that are applied.

Nevermind LibreOffice Draw, you can use LibreOffice Writer to author the actual content. That this is never seriously pushed as an option (even, to my knowledge, by the LibreOffice folks themselves) is an indictment of the computing industry.

Having said that, I guess there is some need to curate a set of templates for small and medium size businesses who want their stuff to "pop".

This guy gets it.

Great way to put it. One thing that I keep trying to hammer is that the "minimum thing" here looks more like "open up a word processor, use the default settings, focus on capturing the content—i.e. writing things out just as you would if you were dumping these thoughts into a plain text file or keeping it to, say, the subset of Markdown that allows for paragraph breaks, headings, and maybe ordered and unordered lists—and then use your word processor's export-to-HTML support to recast it into the format that lets use their browser to read it, and then FTP/scp/rsync that to a server somewhere".

This sounds like I'm being hyperbolic, and I kind of am, but I'm also kind of not. The process described is still more reasonable than the craziness that people (HN- and GitHub-type people) end up leaping into when they think of blogging on a personal website. Think about that. Literally uploading Microsoft Word-generated posts to a server* is better than the purpose-built workflows that people are otherwise coming up with (and pushing way too hard).

(*Although, just please, if you are going to do this, then do at least export to HTML and don't dump them online as PDFs, a la berkshirehathaway.com.)

That neither content creators nor browser vendors are particularly concerned with the production and consumption of documents, as such, is precisely the issue. This is evident in the banner that the majority of the work has occurred under over the last 10+ years: they're the Web Hypertext Applications Technology Working Group.

No one, not even the most well-intentioned (such as the folks at Automattic who are responsible for the blogging software that made Christina's post here possible), see documents when they think of the Web. No, everything is an app—take this page, for example; even the "pages" that WordPress produces are facets of an application. Granted, it's an application meant for reading the written word (and meant for occasionally writing it), but make no mistake, it's an application first, and a "document" only by happenstance (i.e. the absence of any realistic alternative to HTML & co for application delivery).

I've explained such a system, and promised Andy Chu an example that I've yet to be able to complete, but it comes down to this:

A website is fundamentally a document repository. One of the first documents that you should store in that repository is one which explains, in detail, the procedures for provisioning the host powering the site and how content gets published. (Even better if it's so detailed that the procedures exhibit a degree of rigor such that a machine can carry them out, rather than requiring manual labor by a human.)

Though it’s described in such a simple way, there might be hidden power in adding these tags, especially when we bring eBooks to the Semantic Web. Though books are the prime example of a “Web of Documents”, they can also contribute to the “Web of Data”, if we enable them. It might take long, but it could happen.