Re: Comments on ActivityStream Vocabulary

Hello,

I came across a couple more things as I have manually reviewed my
implementation against roughly half of the 159 examples. I realize in the
big picture, some of these are minor details. However, since I am trying to
wrap a static type system around this specification, any clarification
really does help.

1. Example 58 of the spec contains the following example for the Mention
type:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "summary": "Mention of Joe by Carrie in her note",
  "type": "Mention",
  "href": "http://example.org/joe",
  "name": "Joe"
}

However, the presence of "summary" in this example is conflicting with the
rest of the document. The domain of the "summary" property type is only
"Object", supported by the "Object" type listing "summary" as a property
while "Link" does not. Since "Mention" extends "Link" and not "Object", it
does not inherit the "summary" property. Thus, there is a contradiction
between this example and the specification.

2. Examples 79 & 80 both have the following snippets:

{
  "type": "Image",
  "name": "Note icon",
  "url": "http://example.org/note.png",
  "width": 16,
  "height": 16
}

However, the "width" and "height" properties both only have a domain of
"Link". The "Image" type extends "Document" which extends "Object", none of
which have neither the "width" nor "height" properties. So this is the same
kind of conflict between specification and example as #1.

3. The Tombstone "formerType" property lists "Object" as its range, but
based on examples it looks like it should have the same range as the "type"
property, which is anyURI. That is, it is unclear what putting an entire
"Object" type into the "formerType" property would effectively mean.

4. Example 60 is missing its "@context" property with value "
https://www.w3.org/ns/activitystreams".

5. Based on examples, it seems like certain properties are expected to be
serialized as JSON arrays even when containing only one element. These
include the properties:
- "attachment" (Example 66)
- "attributedTo" (Example 67)
- "bcc" (Example 70)
- "bto" (Example 71)
- "cc" (Example 72)
I realize these are non-functional property types and therefore could have
multiple values. But since these examples deviate from others, they may
lead to confusion where an implementor mistakenly believe there is an
implication to be had, when in reality it makes no matter if the property
value is a single value or an array with a single value. So this just seems
to be a stylistic inconsistency, as some examples of other non-functional
properties that are never shown as JSON arrays with a single value:
- "summary"; is never: [ "Sally offered a post to John" ] in examples
- "name"; is never: [ "My cat taking a nap" ] in examples
- "content"; is never: [ "This is what he looks like." ] in examples

Again, I appreciate any and all clarification around this.
Cory S.

On Wed, Dec 27, 2017 at 6:42 PM, Cory Slep <cjslep@gmail.com> wrote:

> Greetings!
>
> Background: I am in the process of implementing ActivityStream's
> Vocabulary (https://www.w3.org/TR/activitystreams-vocabulary/) in a
> golang library, taking advantage of the language's static typing. This has
> led me down a path of code generation, which allows me to translate the
> specification quite literally into code, and from there generate the actual
> implementation code.
>
> Since I am able to translate the specification definitions into code
> first, I am able to run some sanity checks to make sure they are set up
> properly. After I fixed my personal mistakes, I was left with several
> discrepancies I would like to get resolved:
>
> - The "altitude" property has domain "Object" in Section 4, but the
> "Object" class does not list "altitude" as a property in Section 2.
> - The "id" property has domain "Object" and "Link" in Section 4, but the
> "Object" and "Link" classes do not list "id" as a property in Section 2.
> - The "type" property has domain "Object" and "Link" in Section 4, but the
> "Object" and "Link" classes do not list "type" as a property in Section 2.
> - The "attributedTo" property has domain "Link" in Section 4, but the
> "Link" class does not list "attributedTo" as a property in Section 2.
>
> After code generation, I can run the test suite of examples against the
> resulting implementation. I have found an additional area where I need
> clarification:
>
> - The "orderedItems" property is omitted from the spec and only present in
> examples. Therefore, for an OrderedCollection there is no guidance on how
> to resolve "items" and "orderedItems" if one or both are present. Nor is
> there guidance whether a Collection with "orderedItems" is in or out of
> spec.
>
> Finally, I have a question about the use intended resolution of IRIs given
> instead of inlined data. I may have missed it, but I am unsure if
> ActivityStream implementations are required to resolve IRIs at all. That
> is, if a property is an IRI instead of inlined data, I am unsure what
> degree of compliance is required by the spec especially if resolution is
> not an ActivityStream type:
>
> 1. Not resolving IRIs at all and ignoring just those fields that are not
> resolved to an ActivityStream object.
> 2. Not resolving IRIs at all and ignoring the entire message if any of
> those fields are not resolved to an ActivityStream object.
> 3. Resolving with a GET request and ignoring just those fields that are
> not resolved to an ActivityStream object.
> 4. Resolving with a GET request and ignoring the entire message if any of
> those fields are not resolved to an ActivityStream object.
>
> Practically, it seems like a mix of #3 and #4 would manifest in
> applications. But is this the desired outcome?
>
> I welcome all feedback and responses.
>
> Thanks,
> Cory S.
>