Show newer

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb i mean maybe i'm coming out as against websockets here, but idk, honestly i don't have to deal with these problems often enough to have a strong opinion

i think the easy case is easy and reachable with just XML, and maybe there's a more efficient, complex case which can be built on top of it, but the easy case should still be possible regardless

@gaditb this is very fucked up, just imo, but that's what it is

@gaditb did: is an IRI format which specifies a resolver (plc?) and a resource key; at:// is a protocol which takes a DID and indicates that it should be accessed using the AT protocol and then that the path should be followed (side-note: IETF does not like the name at: but has no mechanism by which to disallow it)

so this is saying

Access [PLC DID] with AT and then access the [app.bsky.feed.post] collection and then access item [ID] within it

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb i think web/Unix/“view source” philosophy is that the result of any request should be a document, yeah

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb i think i'm mostly in agreement but my sticking point is that if you want document structure to survive data transformation then you need to pick a document structure and stick with it conceptually, even if the view only exposes a subset

i think that the document structure you should pick should be conceptualized as XML Infoset as early in the process as possible, so that all your transformations are conceptually XML Infoset to XML Infoset, even if you're using a syntax which only actually exposes a part of that

i care less whether you're actually serializing that as XML, although I think Unix philosophy would state that at application boundaries you should be

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb like i actually care a lot more about XML Infoset as a baseline than XML the set of strings which match the document production specified in the eXtensible Markup Language specification (version 1.0 or 1.1)

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb ah yeah, i mean i’m very in favour of e.g. having an underlying dataset you can represent as RDF/XML or RDF Turtle or JSON-LD, and likewise the ability to represent a document in a lightweight syntax that converts to and from XML trivially…

…although practically, i think the source serialization DOES matter. it’s really really hard to write a transform for Any RDF/XML Document but it’s really easy to write one for an RDF/XML document which follows An Exact Structure. that’s why XMP and ActivityStreams both specify limitations on the actual transmission format that implementations need to follow, even though hypothetically there are a number of different ways of conveying the same thing

i think that it’s not really possible to avoid the meta-data of document structure as being a PART of how you work with and process that data. i like XML here mainly because “document structure” in XML is exceedingly well-defined. even IF you’re actually going back and forth with something else when you edit

Re:(5) New blogpost: Programming Resolutions for 2024 

@gaditb the significance of XML to me is the fact that it is fairly trivially convertible to HTML (or styleable with CSS directly) [or turn it into SILE if that's your fancy]

this is a practical concern not a technological one; the most portable formats for display are XML, and if that’s your destination format, it seems helpful to maintain that as far up the chain as you can

otherwise, surely they’ve developed something in the Lisp universe for this, right? isn’t that kind of the whole point?

is www.gnu.org down for anybody else or is it just me

prrgrrmmng 

programming languages that do one thing well are great

like Makefile and executing shell commands to update files

or XSLT and transforming XML trees

or Ruby and making it impossible to know where any one method is defined

love them for that

@djsundog if you knock on someone's door christmas eve and they don't offer you a cookie they get what's coming to them, i say

Lady boosted

But the shot just missed
me and struck the man on my
right full in the chest

re: prrgrrmmng 

@aschmitz i mean yeah, regular expression matching can be simple and fast

prrgrrmmng 

libxslt has a (configurable) maximum recursion depth of 1500 which does mean that if you can’t reasonably chunk your markup language into smaller pieces than that you can probably only process things which are very small

i bet you could write an efficient djot parser for it though

Show thread

prrgrrmmng 

what if we only used markup languages for which it is possible to write a parser in XSLT 1.0 + EXSLT

oh my god it’s a live dom iteration bug isn’t it why would you do this to me

Show thread

is the rss feed for my statuses… skipping every other paragraph?!

Show older
📟🐱 GlitchCat

A small, community‐oriented Mastodon‐compatible Fediverse (GlitchSoc) instance managed as a joint venture between the cat and KIBI families.