-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formal Specification #47
Comments
i find the idea of a text-based spec file great. I'd love for it to be the source of the website. Maybe through a library like showdownjs or something else. The reason this project started was to contain all the info we gathered so far and to standardize the project in a more formal way than just a couple of blogs combined. I think you can start by filling in the details of stuff that's already agreed upon and file issues/questions in discord if they don't exist already. The discussion for those items can happen there. If the setup is right it'd be easy to add the blanks (those refered issues) at a later stage. Please also keep in mind that we define a couple of versions. This is currently not visible on the website, but should be (#41 ) A structure could be:
etc Todo
|
All right, thanks! I will try to leave out the parts that are still undecided. There will be some points where I will have to make some decisions (e.g. about white space) but I will try to highlight those for further discussion. I'd prefer if at least for now we would just have a single Markdown document for the specification and just hightlight parts that have been added/removed/changed in different versions. At least for the beginning this would simplify the process significantly and avoid having different files containing contradictory specs. I think it would make sense to extract the fixed-version specs at some point in the future when the fundamentals have been decided on. |
Sounds like a good way to go! 🎉 |
I have created a first draft PR so that people can see the progress. There is still some work to be done (and some ideas that probably should be removed for the first PR) but the PR should still show the direction I'm going in. This discussion should probably be continued in the PR. |
I agree with you, a textbased spec file (md) is good and it would be awesome if we can use it as source of the website. |
Suggestion
There should be a more formal specification of the file format. I suggest that the specification is maintained in a text file (markdown or Plain text) in this repository (and then potentially embedded in the website as well).
The website could serve as an overview aimed mainly at non-developers and could Highlight relevant features of the spec (as it does now). As an example https://tus.io/ does something similar (They have the FAQ section with an overview and the formal spec on the „Protocol“ page).
Use case
Currently the official spec seems to be the HTML-formatted website. While the website provides a convenient introduction and overview of the format it‘s currently missing many of the technical details. At the same time many end users are probably not interested in those details.
As a developer a more technical specification is really helpful when implementing parsers, generators and other software interacting with the format.
A simple text file has advantages over the HTML format because it makes it much simpler to create and review PRs with changes to the spec. Otherwise the HTML/CSS/design gets mixed with the spec discussion and limits potential contributors from proposing changes.
Extra info/examples/attachments
I‘d be happy to submit a PR with a first draft of a more formal specification if this is wanted. However, I‘m not sure what the best process is. The spec would contain a lot of small details that probably need to be discussed (See #46, #44, #43, #18). Having many different things in a single PR could be difficult to discuss. Maybe a maintainer could give me some guidance about the best process?
Also the question posed in #41 applies here as well: should there be a single spec that includes changes in newer versions or a standalone spec per version.
The text was updated successfully, but these errors were encountered: