Create 2026-07-29.md - #810
Conversation
| * RZ: Exactly the issue. But unfortunately RDF is not sufficient; XML is ugly in this way. Sacrifice is needed somewhere anyway. | ||
| * Th: There is a markdown that is bit more readable that can compile to RDFa | ||
| * ...: Is there an editor plugin to make it more readable | ||
| * eP: There is no one editor everyone is using, maybe LSP? |
There was a problem hiding this comment.
@elf-pavlik dokieli ( https://dokie.li/ ) is an RDFa editor with a team who is very active in the Solid CG. We would appreciate your supporting our work as chair of the CG, and perhaps encouraging adoption of our own tools.
There was a problem hiding this comment.
I meant code-editor. People are using VSCode (and all its forks), NeoVim, Zed, Emacs, Sublime, Webstorm, IntelliJ, Helix etc.
While I appreciate dokieli's team efforts, the big promise of Solid is that each user can use whatever app they like. When it comes to the specs we rely on git not solid, text files and build/ci steps to produce final documents. If dokieli can produce those files in a way that someone can make a PR, that's amazing! Nice to have another option to choose from 👍
There was a problem hiding this comment.
dokieli already reads from and writes to git repositories (GitHub and Forgejo/Codeberg). Each save is a commit on a branch, so opening a PR from it is the normal forge flow. The "if dokieli can produce those files" framing doesn't apply: it can, and has been able to for some time. When the target is a .md file it serializes to Markdown, retaining the semantics as much as Markdown allows.
To be clear, I'm not interested in arguing this to death, and I agree nobody should be mandated a tool; author in whatever you like. It just struck me that "we rely on git, not Solid" is a missed opportunity: it would be nice if the CG could also say it relies on tools built on its own specs, at least as one option among the editors you listed.
Happy to demo the git workflow if that would help inform the discussion.
There was a problem hiding this comment.
Can you demo Vim mode, Emacs mode, Helix mode, Kakoune mode, Sublime mode etc. ?
There was a problem hiding this comment.
@VirginiaBalseiro you and all CG members can always do demos, please just add it to the https://hackmd.io/@solid/cg-weekly or even just show up and offer to do a demo.
My main point is - for editing spec that aim to go through W3C process, I consider https://github.com/speced as a baseline and currently Github de facto collab space.
I'm also happy to experiment with using Solid apps in CG interactions. A low-hanging fruit from my perspective would be simple 'mark yourself present' where various apps would allow anyone to do it with a simple tap, rather than type/paste name in hackmd. Bit higher hanging fruit, something like https://github.com/hackers4peace/sai-js/tree/main/examples/plenary or fixing calendars / scheduling / RSVPs in general.
Starting with using Solid to edit Solid spec, feels to me like starting a programming language with self-hosting and skipping bootstrap phase. I don't expect anyone to agree with me but personally I would be more interested in simple low-hanging fruit like 'mark yourself present' - one tap on mobile ✅
There was a problem hiding this comment.
BTW, in "who does the job, calls the shots" spirit. I think scribe should decide on the tool they want to use. If someone who scribes wants to use dokieli or anything else that allows others to make real time corrections, I think that would be cool! In the end it just needs to end up in a PR like this one.
There was a problem hiding this comment.
The Vim mode question is a strawman. I didn't ask anyone to demo their editor, I offered to demo one tool against the bar you set: produce the files, end up in a PR. I'd appreciate the offer being engaged rather than mocked, particularly from the chair.
re: the whole bootstrap analogy - Solid is over ten years old and dokieli is older than this CG, there's no bootstrap phase we're waiting on. Also nobody suggested changing the CG's workflow. A scribe can use dokieli lands as a Markdown commit in a PR like this one. That's it, take what you want from that.
And honestly, the examples you give of what tasks you'd like to start with for using Solid in the CG read to me like Solid apps are ok for toys but the real work stays on GitHub forever. That's exactly the thing I was pushing back on.
Anyway, scribes pick their tools. The option is there.
There was a problem hiding this comment.
My point was that no tool, including dokieli, can satisfy everyone's needs. That's why everyone should be able to pick a tool that suits them. Git enables it pretty well, Solid should enable it to.
If dokieli can produce those files in a way that someone can make a PR, that's amazing!
I'm setting no bar here, simply stating that current workflow is based on git and github PRs and any tool that can accomodate it should do, including dokieli for whoever wants to use it. Again we <3 demos, so whenever you like to do one please go ahead.
As for RDFa that's another story, I don't find it fit for human consumption. Very recently I was struggling again trying not to have to look at that gibberish:
No matter how it was produced, as a rewiever my experience so far is that RDFa in specs tends to be a major PitA, and I know I'm not alone not excited to have to look at it. There's always option to provide human readable diff or PR human readable text first for review and add the machine readable noise after the review. I'm probably expecting too much of a good will.
|
Unfortunately I wasn't able to make it to the meeting to fill in some information / knowledge that appears to not have been communicated (or may have been taken for granted). Well, at least in the minutes. The CG has done considerable amount of work in the Solid QA initiative: https://solidproject.org/ED/qa , and there are loads of examples and explanations across the meeting minutes, mailing lists, issues, chats, and so forth.
What/Which "formal vocab"?
Could you expand on measurable improvements, assumptions, or criteria that's being considered here? The Solid Protocol (among several other specs) is already human- and machine-readable in HTML+RDFa. A single resource accessible from any server on the face of the planet that can serve an HTML document. No information is duplicated, and this is important. They are 100% self-describing documents: https://www.w3.org/2001/tag/doc/selfDescribingDocuments .
That seems to be what we've been encouraging in https://solidproject.org/ED/qa . Have you seen the Conformance sections of some of the Solid specs and their source?
Unfortunately https://services.w3.org/htmldiff is no longer cooperating with text/plain that's returned from raw GitHUb URLs. That is why I didn't include the Diff link to it. I've introduced the Preview and Diff links into the Solid CG PRs as a practice so I can assure you that I am interested in making things accessible to more people. We can of course diff a copy of the contents of the reference/new documents from somewhere else that returns a text/html or find other ways so that the raw HTML of the Solid Protocol can be diffed. In the meantime, you could clone the branch and view the HTML locally, or see the Preview (htmlpreview) link in the first comment or githack etc. If those are still inadequate for your needs at this time, you can also choose not to review. But, we are happy to explain the PR to you.
I don't quite follow this - am missing context, criteria, etc.
As some of you may know, Markdown+RDFa is not "standardised" yet but there are a few options. I can't expand on this / links right now but there has been several people discussing this topic in the dokieli Matrix chat. We in fact implemented this based on those requests and discussions. And open to adopt any appropriate specification. Dokieli is able to retain RDFa properties when converting to Markdown, by keeping the markup intact when it comes across properties known to dokieli (those that can be added via the dokieli UI). We thought this to be an okay middle way. |
Markdown or minimal html diffs work perfectly fine in github PR and all the tools that integrate with it.
You can also PR human readable text first, which at least for new additions would offer a clean diff, and add machine readable noise later. It would add an extra step for one human editor but would be more accessible for hopefully many human reviewers. |
|
On a positive note and in the spirit of contributing and improving the ecosystem that characterises us :) we've done a simple extension to what we already had in dokieli to actually do a diff preview using the Application Capability mechanism ( see also #806 ). Hope this helps you to read: https://dokie.li/#diff=https://raw.githubusercontent.com/solid/specification/a4b9b19e7354cc8dc994d61a984f4eea140eab6e/ED/protocol.html&diff=https://raw.githubusercontent.com/solid/specification/28804abe2f0e40904763d4011693129083e2b4fc/ED/protocol.html |
|
Thank you @VirginiaBalseiro much appreciated! dokieli has a lot of green so it still takes some effort to skip over notes and references but it is much much better than trying to 👀 parse RDFa 👏 |
3 participants
No description provided.