-
Notifications
You must be signed in to change notification settings - Fork 25
Markdown updates for 1.1.0 #279
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @teemukataja, good work but I spotted several things to fix:
- the title still says v1.0.0
- In "Beacon object", the example for
apiVersion
still saysv1.0.0
(not sure if it's necessary to update it as it's just an example, though). - in
BeaconAlleleResponse
the fieldbeaconHandover
is missing. - in
BeaconDatasetAlleleResponse
there is a fieldbeaconHandover
but it should bedatasetHandover
. - the examples you pasted do not have these new fields
beaconHandover
ordatasetHandover
. - definition of ADA-M object has not been updated. In the table where
adamDataUse
is listed, we should add a link to the repository as we do withconsentCodeDataUse
field, and remove the section "Adam Data Use object".
WDYT @juhtornr? Is there any reason to explain the fields, endpoints, parameters, etc, again in beacon.md? Because I agree with @teemukataja: it's annoying to maintain this file. I suggest:
|
Markdown from YAML?! We generate the whole set of SchemaBlocks examples and .md ... from the YAML file through a simple Perl script. E.g. leads to
Sorry in case I misunderstood the problem ... |
This is very convenient for the .md files! (not so sure for the examples because we are currently showing real examples from a Beacon implementation, not theoretical examples) |
@sdelatorrep Is there a planned transition to JSON Schema? Since we'll do the same for SchemaBlocks (documentation from schema using some "standard tooling" - ask @relequestal... - && doc for website as now. |
I think that it doesn't make sense to keep the same information in two different places. We should have just one place where the information is so therefore I agree with your proposal. |
Title now says v1.1.0
No longer applicable, as objects were removed.
Added.
No longer applicable, as objects were removed.
Added missing fields.
No longer applicable, as objects were removed.
Removed
Kept these.
Kept these. (Although Swagger displays responses as well, but not the requests. Would be nice to remove these as well and only keep example requests maybe?) |
As per request. Instead of copy-pasting from
beacon.yaml
I chose to update only the fields, and add new keys. Although, if you want consistency, I suggest writing examples to the former file and then copypasting the examples to the markdown file.I strongly recommend abandoning double documentation, it is extra work to keep two separate documentation files in sync.