@Lady XML hits limits towards the bottom on how much context you can drop. THAT'S why Markdown appealed to people, it let them drop implicit context and engage with signifucantly reduced friction to the data and method they are inputting.

On the other side of a spectrum, compare Wikipedia's visual editor -- by minimizing the distance between the Reader-view and the ability to make a change, it allows for readers to have a more natural and empowered way of engaging and fixing issues they encounter.
(But also, look at its struggles with visual diffing.)

The s-expression ecosystem has a framework for this, yes -- that's what Domain Specific Languages are, and why so many projects start "first, write a DSL". But that's deeply embedded with s-expressions, and not trivial to make compatible with the unix philosophy.

@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

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

@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

@Lady I think my philosophy (which... I dunno, is this Unix Philosophy?) would state that at the application-to-file-serialization you should, but I think that it would state that at the application-to-application boundary you should consider whether something different and more streamable is better,
like perhaps the format that only exists in my head application/json-seq+ld (application/json-seq, but with a single header JSON object that is a {"@context": ... } that is attached to every subsequent JSON object in the application/json-seq to make them JSON-LD objects.)

Because application-to-application is a different view than application-to-document.

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

@Lady Sure the output, but not necessarily always the input, no? Plenty of pipelines have an "expand to a more streamable format" within them.

@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