Skip to content

Reorganize sections to eliminate redundancy, flow more naturally, be consistent #51

@trwnh

Description

@trwnh

As was discussed in issue #35 but carried over to the rewrite, the report's section hierarchy still shows duplication (albeit improved):

Image

First, Section 5 should be moved up so that it is immediately after Section 2. This would make the report flow more naturally, since "HTML document to ActivityPub object" and "ActivityPub object to HTML document" are mirrors of each other.

More to the point, I think that it would be helpful to clarify the user stories for each section. Specifically, it matters whether the user has dereferenced an HTTPS URL yet or not. Given only an HTTPS URL (as in issue #50 as well), you don't know for sure whether any representations are available until you attempt a request for that HTTPS URL.

The mechanisms described in Section 3 and Section 4 are identical except for the final output. The two sections can likely be reconciled. One possible reframing is to use "HTTPS URL to alternate representation" as a common header, and describe extracting the HTTPS URL from either the DOM location (Document.location or Document.URL) or from the document itself (AS2 id, HTML rel=canonical or rel=self?). This would eliminate the redundancy between Section 3 and Section 4.

A resulting hierarchy for these sections might look something like this:

  • HTML document to ActivityPub object
    • HTML <link> element
    • HTML <a> element
    • HTML <script> element (currently called "Embedded JSON-LD")
  • ActivityPub object to HTML document
    • url property
    • id property (stub that links to next section)
  • HTTPS URL to alternate representation
    • Extracting an HTTPS URL from the current document
    • Content negotiation
    • HTTP Link header
    • WebFinger

Also tangentially, I wonder if it would make more sense to use the term "Activity Streams 2.0 {object|document}" instead of "ActivityPub object". The latter is shorter, but the former is more correct.

Finally, the report should be consistent about the use "Example" or "Examples" subsections. Some sections call it "Example", some sections call it "Examples", and some sections leave it out entirely. Ideally, pick one and use it throughout the report.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions