Skip to content

Add item authors to spec - #120

Closed
croaky wants to merge 1 commit into
manton:masterfrom
croaky:master
Closed

croaky wants to merge 1 commit into
manton:masterfrom
croaky:master

Conversation

@croaky

@croaky croaky commented May 6, 2018 •

Copy link
Copy Markdown

It is common for articles or podcasts to have multiple authors.
Examples include The New York Times and The New Yorker:

#6

Currently, the JSON feed spec allows one author object
on the top-level feed and one on each item:

author: {
  name: "Alice",
  url: "https://example.org/alice",
  avatar: "https://example.org/alice.png",
}

To provide an item with multiple authors,
the author names could be concatenated and URLs and avatars removed:

author: {
  name: "Alice and Bob",
}

Or, the author names could be concatenated
and combined URLs and avatars provided:

author: {
  name: "Alice and Bob",
  url: "https://example.org/alice-and-bob",
  avatar: "https://example.org/alice-and-bob.png",
}

Those use cases might work well when the author is a team:

author: {
  name: "Engineering Team",
  url: "https://example.org/team/engineering",
  avatar: "https://example.org/team/engineering.png",
}

This feels more awkward for use cases of blog posts / news articles
with multiple authors, or podcasts with multiple hosts where
the publisher wants to provide links for each author's individual
identity, such as to a listing of that author's other works.

In those cases, this structure feels nice to me:

authors: [
  {
    name: "Alice",
    url: "https://example.org/alice",
  },
  {
    name: "Bob",
    url: "https://example.org/bob",
  }
]

I can imagine a natural-looking feed reader experience of:

Article Title
by Alice and Bob
May 6, 2018

This change adds authors to items and attempts to make it clear
to implementers how to handle the various present/missing states
for author and authors. Although all use cases can be covered by the
authors array (single author items can be modeled as a one item array),
it does not deprecate author. I leave that decision to project maintainers.

Also, this change does not add authors to the top-level feed.
In my experience, even on publications with multiple authors per item,
the top-level feed author has appropriately been the publishing
company or organization.

It is common for articles or podcasts to have multiple authors.
Examples include The New York Times and The New Yorker:

#6

Currently, the JSON feed spec allows one `author` object
on the top-level feed and one on each item:

```json
author: {
  name: "Alice",
  url: "https://example.org/alice",
  avatar: "https://example.org/alice.png",
}
```

To provide an item with multiple authors,
the author names could be concatenated and URLs and avatars removed:

```json
author: {
  name: "Alice and Bob",
}

Or, the author names could be concatenated
and combined URLs and avatars provided:

```json
author: {
  name: "Alice and Bob",
  url: "https://example.org/alice-and-bob",
  avatar: "https://example.org/alice-and-bob.png",
}
```

Those use cases might work well when the author is a team:

```json
author: {
  name: "Engineering Team",
  url: "https://example.org/team/engineering",
  avatar: "https://example.org/team/engineering.png",
}
```

This feels more awkward for use cases of blog posts / news articles
with multiple authors, or podcasts with multiple hosts where
the publisher wants to provide links for each author's individual
identity, such as to a listing of that author's other works.

In those cases, this structure feels nice to me:

```json
authors: [
  {
    name: "Alice",
    url: "https://example.org/alice",
  },
  {
    name: "Bob",
    url: "https://example.org/bob",
  }
]
```

I can imagine a natural-looking feed reader experience of:

```
Article Title
by Alice and Bob
May 6, 2018
```

This change adds `authors` to `items` and attempts to make it clear
to implementers how to handle the various present/missing states
for `author` and `authors`. Although all use cases can be covered by the
`authors` array (single author items can be modeled as a one item array),
it does not deprecate `author`. I leave that decision to project maintainers.

Also, this change does not add `authors` to the top-level feed.
In my experience, even on publications with multiple authors per item,
the top-level feed `author` has appropriately been the publishing
company or organization.
@croaky

croaky commented Jun 18, 2018

Copy link
Copy Markdown
Author

Howdy, folks! Thoughts on this idea? Cheers.

@matwood

matwood commented Oct 8, 2018

Copy link
Copy Markdown

Agreed, although I do think the Atom spec should have been followed here where all author items are lists. See feed https://tools.ietf.org/html/rfc4287#page-11 , and entry https://tools.ietf.org/html/rfc4287#page-11 .

Since author is already out in the wild, adding authors to each level as part of the spec would at least allow additional authors.

@croaky

croaky commented May 29, 2020

Copy link
Copy Markdown
Author

Cleaning up some old PRs. Okay to close this?

@manton

manton commented Jun 1, 2020

Copy link
Copy Markdown
Owner

Thanks @croaky! Yes, multiple authors are in the version 1.1 draft, so I'll close this.

@manton manton closed this Jun 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants