Skip to content

Change normative language in Microsyntax non-normative section #627

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
evanp wants to merge 3 commits into from
Closed

Change normative language in Microsyntax non-normative section #627

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9d76d85
Change normative language in Microsyntax non-normative section
evanp Dec 6, 2024
ba6eb83
Clarify non-normative section on microsyntaxes
evanp Feb 27, 2026
6fe3ef7
Apply suggestion from @csarven
evanp Mar 20, 2026
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
2 changes: 2 additions & 0 deletions ERRATA.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,3 +80,5 @@ This document includes errata for the [Activity Streams](https://www.w3.org/TR/a
- Unlike `latitude` and `longitude`, the domain of the `altitude` term is the `Object` type. The `altitude` term should be included in the list of properties of an `Object`. Because `altitude` is primarily documented as a property of a `Place`, publishers should not include `altitude` on objects that are not of type `Place`, and consumers should accept objects with this property that aren't of type `Place`.

- The domain of the `attributedTo` property is both `Link` and `Object`. `attributedTo` should be included in the list of properties of a `Link`.

- The second paragraph in the non-normative section "Mentions, Tags and Other Common Social Microsyntaxes" contains RFC 2119 capitalized terms like MAY, SHOULD NOT, and SHOULD, which gives the impression that the requirements are normative. One solution is to replace the capitalized terms with equivalent terms that don't suggest normative requirements: 'While such microsyntaxes can be used within the values of the `content`, `name`, and `summary` properties on an Activity Streams Object, implementations cannot be expected to parse the values of those properties in order to determine the appropriate routing of notifications, categorization, or linking between objects. Instead, publishers are encouraged to make appropriate use of the vocabulary terms provided specifically for these purposes.'

@TallTed TallTed Apr 2, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Rather than a new PR, which pretends that the discussion in this PR #627 didn't happen, the changes now in PR #676 should have been incorporated here, via a suggestion like this --

Suggested change
- The second paragraph in the non-normative section "Mentions, Tags and Other Common Social Microsyntaxes" contains RFC 2119 capitalized terms like MAY, SHOULD NOT, and SHOULD, which gives the impression that the requirements are normative. One solution is to replace the capitalized terms with equivalent terms that don't suggest normative requirements: 'While such microsyntaxes can be used within the values of the `content`, `name`, and `summary` properties on an Activity Streams Object, implementations cannot be expected to parse the values of those properties in order to determine the appropriate routing of notifications, categorization, or linking between objects. Instead, publishers are encouraged to make appropriate use of the vocabulary terms provided specifically for these purposes.'
- The second paragraph in the non-normative section "Mentions, Tags and Other Common Social Microsyntaxes" should read, 'While such microsyntaxes can be used within the values of the `content`, `name`, and `summary` properties on an Activity Streams Object, implementations are not expected to parse the values of those properties in order to determine the appropriate routing of notifications, categorization, or linking between objects. Instead, publishers are expected to make appropriate use of the vocabulary terms provided specifically for these purposes to communicate information to consumers.'

@trwnh trwnh Apr 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

evan made a new pr because this one had unresolvable merge conflicts.

@TallTed TallTed Apr 6, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@evanp made a new pr because this one had unresolvable merge conflicts.

Well, that's frustrating, on multiple levels.

In future, best to comment about such "unresolvable merge conflicts" when closing the PR.

(I've never seen "unresolvable merge conflicts," only "merge conflicts that take significant time and effort to resolve." When I've been involved in such cases, I've made use of an external text editor, usually BBEdit, to manually compare the >>> and <<< sections on a character-by-character level and produce a clean-up commit. I'd be happy to do so for future PRs that are so "unresolvable". Note that I'd need to be granted some extra permissions on the repo, which I'd only use for production of such conflict resolution commits.)

@evanp evanp Apr 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@TallTed let's say that the PR was not resolvable with my level of attention and skill, and that it was significantly easier to do without a merge. If in the future it seems like it would be better to have someone untangle the merges, I'll definitely tag you in!