Edit content-repo.yaml to include examples and headers.
Restructure content module to conform to the module template.
Adjust the HTTP API template to give 1 more char to the response
param to fit "Content-Disposition" correctly.
Edit the templating system to support displaying enums for
swagger APIs (before it was just JSON schema). Also add support
for introspecting headers from swagger. Finally, replace - with
_ when forming the {{ template_var }} else things whine.
For cases where event schema specify `patternProperties` it would be nice
to give that pattern a "human-readable" form rather than a raw regex. This
is now supported by specifying `x-pattern` in the value part of the specified
pattern e.g. `patternProperties:{ "^.*":{ x-pattern: "$THING", ... } }`
Templating had limited record type descriptions limited to value primitives
e.g. `{string: integer}`. It now supports inspecting the values recursively
if the value is `object`.
Updated `m.receipt` to take both these points into account to make it read
better. Tweak receipt module text.
Add table detailing the profiles. Add anchors to link through to each module
following a well-defined format (rather than the name of the module section).
Allow UTF-8 in the spec.
Previously, all `m.room.*` events were wodged into `{{room_events}}` which
isn't great when you want to pull specific ones out. Batesian had a 1:1
mapping of `render_foo()` to a section `{{foo}}`, and having to constantly
add functions for new types is a PITA. Batesian now supports returning a
`dict` instead of a section `string` where the keys are the `{{foo}}` and
the value is what will be inserted. Also add conflicting section key checks
to avoid multiple definitions of the same `{{foo}}`. Define dicts for
event schemata and swagger HTTP APIs.
Using this new feature, split out the instant messaging stuff from the events
section, and replace `{{room_events}}` with a list of specific events e.g.
`{{m_room_member_event}}`.
If an HTTP API returned a top-level array response, the templating system
would fail to create a table for it. This is now partially fixed by pulling
out the type of the elements (no recursion is done to populate nested tables)
Templates don't know at what level they will be inserted. Previously, we
hard-coded the title style which is not compatible with the build target
system. Define a set of styles which will be replaced by the gendoc script
when it encounters them:
'<' : Make this title a sub-heading
'/' : Make this title a heading at the same level
'>' : Make this title a super-heading
The build target system is now basically complete and functioning.
Rename "schema/v1/core" to "schema/v1/core-event-schema".
Add self-referential symlinks to schema/v1/core-event-schema
The python json schema libraries expect that relative references are
relative to the file they are in. The node json schema libraries
expect that relateive references are relative to the first file loaded.
To support both kinds we reference the core event schema using
"core-event-schema/event.json". We then symlink the core-event-schema
directory to both the location of the file refering to "event.json" so
that it will work in python and to the location of the top level file
so that it will work in node.
This is just replacing the existing spec with a swagger version.
Subsequent pull requests will add 3pid join to this, as well as specing
the invite, leave, ban, and kick endpoints.
Hook up templating system to read the CHANGELOG for version and changelog info.
Modified nature.css to make it clearer on table headings/sub-headings. Use the
full _matrix/client path on title links to make it clear it is for v1.
Use 'x-example' to add examples to parameters which are not in 'body' (swagger
doesn't define that currently). Add profile API examples. Add necessary glue
and templates to make it all work.
Restructured the sections code to be slightly more encapsulated than before.
This will be expanded to more clearly separate the templating system from
the specific implementation of the spec templates.
This allows us to incrementally convert sections of the spec to use this
templating system. E.g. './build.py ../specification/20_events.rst' where
that .rst file has {{room_events}} in it somewhere. Add ability to show
a list of valid template vars to use (e.g. room_events) by running
'./build.py --show-template-vars'.
Kegan Dougal