Lady of Misrule @Lady@cat.family

by reading RDFa metadata, the web standard developed in 2008 to support precisely this functionality…… right?

dunno what this means but i’m sure it’s fine

maybe i need to get into illumos or smth

i would switch to a B·S·D if every B·S·D didn’t give vibes of being staffed entirely by missing stairs

apparently this is just not documented Anywhere, Thanks

what version of unicode is used for APFS, for example? the original specification says Unicode 9.0, but i can make files named “🥠” on my computer today

does apple update Unicode data for old, yet still supported, versions of macOS?

tfw u realize you might have to upgrade to the a·i edition of macOS because u have a hard dependency on Unicode 16

so many formats these days are just specially-engineered zip files and there is no Posix way of engaging with them

somebody in the Austin Group standardize zip pls

the use of <书社:link xlink:href="about:shushe?include=things/"> as a shorthand for doing a link with every file nested in things/ is definitely a little conceptually sus, especially once i get to supporting @xlink:show values other than "embed", but it is so convenient 😔

the approach is to define a

<x:wrapper>
<书社:link xlink:href="about:shushe?include=things/" xlink:show="embed"/>
</x:wrapper>

which then gets all the files in $(INCLUDEDIR)/things/ and transforms to a

<书社:archive 书社:expanded="">
<html:article 书社:archived-as="index.html"><!--…--></html:article>
<!--…-->
</书社:archive>

not hard to do at all

the thing with the approach of “treat everything as an include, create a conceptual archive containing the entire site, and then extract that into public” is that (1) being able to just xpath into any file at any time is actually extremely powerful, and (2) this does just mean loading your entire site into memory and doing every transformation on it all in one go

this was a site with no scripting, to be clear

they were doing source code transformations on typescript in there

one time someone in fandom coders was complaining because their static site generator took like 10 seconds to rebuild their very simple site and i was just like “…what are they doing in there?”

unrelatedly, i AM working on building a unified RDF/OWL ontology for my projects using ⛩️📰 书社 and it IS definitely stress-testing its capacity to handle “actual workloads”

jury is still out whether something complexly interconnected like that or something with Just A Lot Of Data (e·g a dictionary) will bog it down more

but i’m pretty sure it’s still faster than Any Static Site Generator

“just define a conceptual tarball and expand it” feels kludgy but solves like 95% of the situations where multiple files need to be produced from a single source file, more elegantly than anything else i’ve been able to come up with

allllll of the “catalog”-related stuff in that makefile is going to be dropped, tho, and possibly also the subrepo approach in favour of expecting users to stich things together in the downstream repo

basically i am leveraging the “expanded archive” functionality from ⛩📰 书社 to take this down to a single .xslt file, which really makes one wonder whether this needs a whole dedicated git repository, although i probably will keep it for the `make +category` functionality which is convenient and nontrivial