Specification next/previous modelled as lists

[darobin]

Currently, the JSON returns for next and previous on specifications are modelled as lists. This may be correct (though I can't find examples) but it's hard to guess since before of #20 they show up as scalars anyway.

If there is only ever one prev/next, these should be exposed as scalars directly and not a pageable result.

If they are meant to be exposed as lists, then it would be very nice if the field name in the list results' _link were called next and previous instead of the current versions. In most of the rest of the API, there is a mapping there, but not here. That means ad hoc code to access these specific fields.

Similar questions apply to supersede(d|s).

[deniak]

It's not common but when you have a specification splits or merges, next and previous will have multiple items, e.g. https://api-test.w3.org/specifications/CSS2/versions/20090423/previous and https://api-test.w3.org/specifications/XMLHttpRequest/superseeds.

I'll rename the fields in the results list.

[deniak]

@darobin the fix is now deployed

[darobin]

Verified and shipped a new version to match. Thanks!