Disjointness of Activity Streams types

[silverpill]

Activity Streams 2.0 defines 8 core types and a bigger number of extended types. All of them are sub-types of either Object or Link, which are described as disjoint, but specification doesn't say anything about disjointedness of derived types.

There are two situations where disjointness may matter:

• Sub-typing. Is it possible to define a new type that extends two or more core types (e.g. Activity and Collection)?
• Multi-typing. Is it possible to create an object with two or more extended types (e.g. ["Accept", "Person"])?

Most (if not all) of these combinations don't make sense, and as an implementer I would prefer to not deal with them, and fortunately I don't have to, because existing implementations don't use combinations. However, while there is no guidance on working with combinations of standard types, they are not explicitly forbidden. One of the core types, OrderedCollectionPage, is even defined as a sub-type of both OrderedCollection and CollectionPage, implying that multiple inheritance is possible.

Proposal

• Discourage the use of type combinations in a Primer page (both multiple inheritance and multi-typing). Note that this only applies to standard types; for extension types, multi-typing is required by the standard.
• Make this a requirement in AS-next. Re-define OrderedCollectionPage as a sub-type of CollectionPage.

Further work (optional)

• Introduce Actor core type, which is disjoint with Activity and Collection (discussion).
• Introduce SpecializedObject core type, which extends Object and is disjoint with Activity, Collection and Actor.

[nightpool]

Why would we discourage combination of types when they make sense? It's perfectly fine for an object to be both an Accept and a Note, for example. Or a Note and a Question. Why does it matter? There's no justification given in this proposal except personal opinion that you "don't want to deal with them". Why don't you want to deal with them?

…

On Sat, Mar 1, 2025, 6:19 AM silverpill ***@***.***> wrote: Activity Streams 2.0 defines 8 core types <https://www.w3.org/TR/activitystreams-core/#model> and a bigger number of extended types. All of them are sub-types of either Object or Link, which are described as disjoint, but specification doesn't say anything about disjointedness of derived types. There are two situations where disjointedness may matter: - Sub-typing. Is it possible to define a new type that extends two or more core types (e.g. Activity and Collection)? - Multi-typing. Is it possible to create an object with two or more extended types (e.g. ["Accept", "Person"])? Most (if not all) of these combinations don't make sense, and as an implementer I would prefer to not deal with them, and fortunately I don't have to, because existing implementations don't use combinations. However, while there is no guidance on working with combinations of standard types, they are not explicitly forbidden. One of the core types, OrderedCollectionPage <https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollectionpage>, is even defined as a sub-type of both OrderedCollection and CollectionPage, implying that multiple inheritance is possible. *Proposal* - Discourage the use of type combinations in a Primer page (both multiple inheritance and multi-typing). Note that this only applies to standard types; for extension types, multi-typing is required by the standard. - Make this a requirement in AS-next. Re-define OrderedCollectionPage as a sub-type of CollectionPage. *Further work (optional)* - Introduce Actor core type, which is disjoint with Activity and Collection (discussion <#633>). - Introduce SpecializedObject core type, which extends Object and is disjoint with Activity, Collection and Actor. — Reply to this email directly, view it on GitHub <#641>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV67TAISDSHRJYMVVO32SG6YVAVCNFSM6AAAAABYEEPXM6VHI2DSMVQWIX3LMV43ASLTON2WKOZSHA4DQOJTGQ4TINQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: silverpill]*silverpill* created an issue (w3c/activitystreams#641) <#641> Activity Streams 2.0 defines 8 core types <https://www.w3.org/TR/activitystreams-core/#model> and a bigger number of extended types. All of them are sub-types of either Object or Link, which are described as disjoint, but specification doesn't say anything about disjointedness of derived types. There are two situations where disjointedness may matter: - Sub-typing. Is it possible to define a new type that extends two or more core types (e.g. Activity and Collection)? - Multi-typing. Is it possible to create an object with two or more extended types (e.g. ["Accept", "Person"])? Most (if not all) of these combinations don't make sense, and as an implementer I would prefer to not deal with them, and fortunately I don't have to, because existing implementations don't use combinations. However, while there is no guidance on working with combinations of standard types, they are not explicitly forbidden. One of the core types, OrderedCollectionPage <https://www.w3.org/TR/activitystreams-vocabulary/#dfn-orderedcollectionpage>, is even defined as a sub-type of both OrderedCollection and CollectionPage, implying that multiple inheritance is possible. *Proposal* - Discourage the use of type combinations in a Primer page (both multiple inheritance and multi-typing). Note that this only applies to standard types; for extension types, multi-typing is required by the standard. - Make this a requirement in AS-next. Re-define OrderedCollectionPage as a sub-type of CollectionPage. *Further work (optional)* - Introduce Actor core type, which is disjoint with Activity and Collection (discussion <#633>). - Introduce SpecializedObject core type, which extends Object and is disjoint with Activity, Collection and Actor. — Reply to this email directly, view it on GitHub <#641>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZCV67TAISDSHRJYMVVO32SG6YVAVCNFSM6AAAAABYEEPXM6VHI2DSMVQWIX3LMV43ASLTON2WKOZSHA4DQOJTGQ4TINQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[silverpill]

Accept, Note and Note, Question don't make sense to me. This is one of the reasons why I don't want to deal with them. The second is extra implementation complexity.

I think justification should be given to allowing documents with unusual types and undefined behavior, preferably in the form of implementations that use them.

[evanp]

This is definitely worth a Primer page. I think having some understanding of how multi-typing and inheritance work in Activity Streams is important. It's definitely waved at in the spec, and could use more clarification.

I am reluctant to see non-backwards-compatible restrictions introduced in future versions of Activity Streams. We can definitely deprecate some behaviours and encourage others, but making strict requirements that previously acceptable features are no longer allowed is probably not the path we need to take.

I am going to mark this issue as Needs Primer. I think it is worth discussing for the next future version, so let's continue there. I would ask @silverpill if you could propose the idea of the Actor or ContentObject types in a separate issue, so we can track them separately.

[silverpill]

if you could propose the idea of the Actor or ContentObject types in a separate issue, so we can track them separately.

I am currently developing these ideas in FEP-2277. Will open issues later if that FEP gains enough support from other implementers.