Comments on ActivityStream Vocabulary

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.