Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

Task: rewrite Solid spec in W3C template #170

Open
RubenVerborgh opened this issue May 14, 2019 · 8 comments
Open

Task: rewrite Solid spec in W3C template #170

RubenVerborgh opened this issue May 14, 2019 · 8 comments
Assignees

Comments

@RubenVerborgh
Copy link
Contributor

The current Solid specification has a couple of issues;

  • It is a collection of Markdown documents, as opposed to a single authoritative document
  • The specification contains parts that are (purposely) not implemented
  • Some parts that are implemented (and necessary) are not in the spec
  • The spec is insufficiently precise to be implemented in an unambiguous way

As such, I propose to start from scratch with a Solid spec in a W3C template, where we pull in curated parts of the current Solid v0.7 spec, with the aim of reaching a v1.0.

@Mitzi-Laszlo
Copy link
Contributor

@elf-pavlik
Copy link
Member

I suggest https://tabatkins.github.io/bikeshed/ many specs on REC track use it and it still allows using convenient markdown.

@justinwb
Copy link
Member

As such, I propose to start from scratch with a Solid spec in a W3C template, where we pull in curated parts of the current Solid v0.7 spec, with the aim of reaching a v1.0.

I'm in 100% agreement with this proposal.

@Mitzi-Laszlo
Copy link
Contributor

Perhaps in a new repo GitHub.com/solid/specification?

@michielbdejong
Copy link
Contributor

+1 to converting the format
+1 to fixing points where the text diverts from current practice
+1 to fixing ambiguities
-1 to "pull in curated parts" if by that you mean making changes to the meaning of the spec
-1 to " the aim of reaching a v1.0" if by that you mean changing its technical details into different ones

In this phase (I would say from now to roughly the end of 2019), we should only change the spec to make it better describe the current practice, or to fix (security) bugs.

@RubenVerborgh
Copy link
Contributor Author

-1 to "pull in curated parts" if by that you mean making changes to the meaning of the spec
-1 to " the aim of reaching a v1.0" if by that you mean changing its technical details into different ones

conflict with

+1 to fixing points where the text diverts from current practice

but I agree with the overall sentiment.

@RubenVerborgh
Copy link
Contributor Author

But really, we should move away from the idea that v0.7 is untouchable, or even a spec. It's mainly a set of documentation written together, without any consensus process or anyone wondering whether something is a good idea. Let's have a minimum of oversight here.

Regarding timeline specifically:

In this phase (I would say from now to roughly the end of 2019),

Why wouldn't we want a v1.0 by the end of 2019?

@RubenVerborgh
Copy link
Contributor Author

@RubenVerborgh RubenVerborgh removed their assignment May 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants