https://blog.ladys.computer/2023-12-17/programming_resolutions_24/

#prrgrrmmng

@Lady I agree about the significance of transformations, but I don't think XML is necessarily necessary for this -- I think there is simply a major ideological/tooling hole here that XML is merely (at present) the only ecosystem with SOMETHING in. (Well, also RDF.)

I think we just, as a programming culture, have SEVERELY underdeveloped the concept of "bidirectional/invertable transformations".
(And its sister-concept of "explicitly-lossy transformations", that label the areas where it loses information.)

Like, in a tree-/graph-format as well, but also even in regular expressions -- there is no current defined syntax for expressing an invertable regex substution, /despite that being literally a simple subset of regex syntax/.

Much less the obvious (and simple but powerful) corrolary, a way to translate that "invertable regex substution" into its inverse, to get free translation to and from.

@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?

@Lady It's the "it seems helpful to maintain that as far up the chain as you can" that I disagree with -- the chain should rather be INVERTABLY TRANSFORMABLE to that (XML is a good framework target for that), but there are reasons to have different representations for different levels and contexts.

The key thing here I'm thinking is that with invertable translations, different translations become different, equally-manipulable, VIEWS of the underlying data. And different views are useful for different types of manipulation. (WYSI*-frameworks compare in this way.)

Like, approaching an unknown format, it's most useful to have access to a verbose, context-embedding view, to be able to grasp the structure in many places. OTOH, for INPUTTING, and also engaging with familiar data, you want as much context-inference as possible.

For diffing, you want a view that most effectively writes one/a few (annotatable) semantic unit(s) per line.

@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

@Lady I think An Exact Structure is something you can define and, crucially, embed into an invertable transformation specific to the particular collection of data and view you wish to have of it.

Like, take one more step with me and look at /user interfaces themselves/ as a (potentially: invertable-but-not-onto) translation.

The text box I'm typing this into right now isn't just a source which Tusky will when I hit Toot! use to fill in the "content" datafield of the Note object -- it is A VIEW of that datafield itself, that is (ideally) maximally useful for me filling it out. An app COULD give me a view that is the entire json-ld, but that would be less convenient for me.

@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