Skip to content
This repository has been archived by the owner on Nov 8, 2024. It is now read-only.

Add a migration guide for 1.0 #51

Merged
merged 4 commits into from
Oct 16, 2018
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,7 @@ This documentation conforms to [RFC 2119][], which says:
tools
additional-information
extensions/index
migration
```

## License
Expand Down
301 changes: 301 additions & 0 deletions docs/migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,301 @@
# Migration Guide

This guide documents all of the changes between API Elements 0.6 and API
Elements 1.0.

## JSON Serialisation

In prior versions of API Element, an element could be serialised in JSON as a
JSON type, or an API Element.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In prior versions of API Elements, an Element (i.e. a type) could be occasionally serialized as a value. This behaviour has since been dropped, so that Elements are always serialized in full form (i.e. as a type, not as a value). For example: ...

What about something like this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's much better, copied this into da2b009.


For example, the string element in the title of the following element is a JSON
value `"empty"` which is not longer valid in API Elements 1.0.

```json
{
"element": "null",
"meta": {
"title": "empty"
}
}
```

Elements must always be serialised as an element, for example the following
would be valid in API Elements 1.0:

```json
{
"element": "null",
"meta": {
"title": {
"element": "string",
"content": "empty"
}
}
}
```

In previous versions of API Elements, both forms were valid so this is not a
breaking change. However, we found multiple implementation that were fragile
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

implementations

and could break when different forms were used.

## Changes to Elements

### Category Element

The `meta` attribute has been renamed to `metadata` in a category element for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But minim still calls it meta? Isn't it a discrepancy now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you maybe confusing meta at the element level, not the attribute called meta in the category element. Which was renamed to prevent confusion between the two.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😄

clarity.

Before

```json
{
"element": "category",
"attributes": {
"meta": {
"element": "array",
"content": [
{
"element": "member",
"content": {
"key": {
"element": "string",
"content": "HOST"
},
"value": {
"element": "string",
"content": "http://polls.apiblueprint.org/"
}
}
}
]
}
}
}
```

After

```json
{
"element": "category",
"attributes": {
"metadata": {
"element": "array",
"content": [
{
"element": "member",
"content": {
"key": {
"element": "string",
"content": "HOST"
},
"value": {
"element": "string",
"content": "http://polls.apiblueprint.org/"
}
}
}
]
}
}
}
```

### Source Map Element

A source map element may contain an optional line and column number to make it
easier to handle source map information, computing the line and column number
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- source map information, computing
+ source map information. Computing

can often be expensive so it may be provider by a parser. Note however that it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

provider -> provided

is optional and it is down the each individual tooling on whether it is
present, some tools only provide line and column number for source maps
contained within Annotation Elements.

```json
{
"element": "sourceMap",
"content": [
{
"element": "array",
"content": [
{
"element": "number",
"attributes": {
"line": {
"element": "number",
"content": 3
},
"column": {
"element": "number",
"content": 2
}
},
"content": 4
},
{
"element": "number",
"attributes": {
"line": {
"element": "number",
"content": 3
},
"column": {
"element": "number",
"content": 10
}
},
"content": 12
}
]
}
]
}
```

### Data Structure Elements

#### Enumeration Element

The layout of the enum element has been altered. The enumerations have been
moved to an enumerations attribute of the element and the content represented
the given value, like in other elements.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the content represented the given value

Reads strangely to me. Perhaps "the content now represents the given value"?


Enumerations themselves are an array of the possible enumerations.

Before

```json
{
"element": "enum",
"content": [
{
"element": "string",
"content": "north"
},
{
"element": "string",
"content": "east"
},
{
"element": "string",
"content": "south"
},
{
"element": "string",
"content": "west"
}
]
}
```

After

```json
{
"element": "enum",
"attributes": {
"enumerations": {
"element": "array",
"content": [
{
"element": "string",
"content": "north"
},
{
"element": "string",
"content": "east"
},
{
"element": "string",
"content": "south"
},
{
"element": "string",
"content": "west"
}
]
}
}
}
```

The intent of the structure was that it represents an enumeration of north,
east, south and west. As the enumerations do not include a `fixed` type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly nitpicking, but I thought cardinal points are title cased in English

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I am refering to the JSON values which are lowercase I don't want to mix the spelling. I've wrapped them in code blocks which I think makes that clearer.

attribute it represents an enumerations where any string is valid and not just
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

enumeration?

the fixed values. This created a limitation that tooling cannot determine the
difference between one of the fixed element enumerations, or a type with a
value. Thus, when the values are fixed they will now include a `fixed` type
attribute as follows:

```json
{
"element": "enum",
"attributes": {
"enumerations": {
"element": "array",
"content": [
{
"element": "string",
"attributes": {
"typeAttributes": {
"element": "array",
"content": [
{
"element": "string",
"content": "fixed"
}
]
}
},
"content": "north"
},
{
"element": "string",
"attributes": {
"typeAttributes": {
"element": "array",
"content": [
{
"element": "string",
"content": "fixed"
}
]
}
},
"content": "east"
},
{
"element": "string",
"attributes": {
"typeAttributes": {
"element": "array",
"content": [
{
"element": "string",
"content": "fixed"
}
]
}
},
"content": "south"
},
{
"element": "string",
"attributes": {
"typeAttributes": {
"element": "array",
"content": [
{
"element": "string",
"content": "fixed"
}
]
}
},
"content": "west"
}
]
}
}
}
```