Re: Should the specs be forked and maintained elsewhere?

from 2018 https://github.com/w3c/activitystreams/issues/479

> Please Indicate One:
>  * [ ] Editorial
>  * [ ] Question
>  * [x] Feedback
>  * [ ] Blocking Issue
>  * [ ] Non-Blocking Issue
>
> Please Describe the Issue:
>
> I see there is a scheduled vote for next meeting on
> https://github.com/w3c/activitystreams/wiki/Extension-process
>
> I am concerned that it overly encourages using w3.org URLs. Specifically
> * (I believe) The CG has very limited capability to affect what URLs like
> https://www.w3.org/ns/activitystreams/dating actually resolve to, making
> it unnecessarily difficult to have extensions whose URLs resolve to good
> human-readable documentation, or even JSON-LD data describing the
> vocabulary (depending on 'Accept' header of the request)
> * As worded, it encourages a bit of a land grab of good extension names as
> soon as a project is even envisioned. It shouldn't be uncommon for
> extension ideas to get started and then abandoned, or started and then take
> quite some time to be defined and 'published' such that no
> backward-incompatible changes are introduced. For example, AS2 itself
> changed 'title' to 'name' or something trivial like this several years
> after a first draft was published.
> * It sounds reasonable to encourage definition extensions in the w3 wiki,
> but in practice it isn't so easy to either create a w3 account, get access
> to editing the wiki (see [nightpool's experience](
> https://github.com/w3c/activitypub/issues/313#issuecomment-397703016)),
> manage changes without git/PRs, or learn any given wiki's esoteric syntax
>
> I really think we should encourage community extensions to be defined on
> URLs outside of w3.org. There should be a clear distinction of
> 'work-in-progress' extensions that brand new extension efforts can use and
> maybe make backward-incompatible changes in all they want. I think these
> extension URLs should always have some sort of 'group prefix' to prevent
> over-eagerness to claim good extension names (e.g. `
> https://extensions.activitystreams2.com/work-in-progress/evanp/dating`)
>
> Several months or years later, when there is a 'v1.0.0' of the extension
> promising not to make backward-incompatible changes, the extension effort
> may want to do a call for implementations and publish an extension URL
> without the 'work-in-progress' warning. (e.g. `
> https://extensions.activitystreams2.com/dating`). At this time, if
> desired, the old work-in-progress URLs can be HTTP redirected to the final
> URLs.
>
> Not all extension-authoring groups may have a good, stable place to serve
> their extension definitions from, so:
>
> I own the following domains and would like to offer them up as a place to
> define both work-in-progress extensions as well as well-defined and stable
> community extensions. I will liberally accept group-namespaced
> work-in-progress extension definitions in their respective git repos:
> * activitystreams2.com -
> https://github.com/gobengo/activitystreams2-extensions
> * activitypub.com - https://github.com/gobengo/activitypub-extensions
>
> I'd also support delegating any 'work-in-progress/{groupName}' directory
> to a git submodule, so innovation can happen in a separate repo unhindered
> by whoever happens to be in charge of the parent repo (whether w3c or me).
>
> I'd be happy for these repos to not be under my username. Really what I'm
> proposing is that brand new just-idea,
> potentially-shifting-under-your-feet, extensions be under
> `/{groupName}/{extensionName}` before taking up top-level names.
>
> Additionally, I would help work on a program to build this repo of
> extensions into a useful website for the community to consume them. e.g.
> for each extension URL:
> * When requested with `Accept: text/html` (e.g. by a web browser), respond
> with good human-readable documentation
> * When requested with `Accept: application/ld+json`, respond with JSON-LD
> describing the vocabulary in terms of rdfs/owl classes, properties, etc.
>
> I think a plan like this will lead to:
> * Removing incentive to grab top-level extension names
> * Faster innovation on work-in-progress extensions
> * Less hangups and debate on Pull Requests into a top-level namespace
> * Better trust that extensions defined outside of work-in-progress will be
> stable, well-thought-out
>

On Thu, Mar 23, 2023 at 6:10 PM Benjamin Goering <ben@bengo.co> wrote:

> I was thinking through this and I found this throwback :)
> https://github.com/w3c/activitystreams/issues/283#issue-132866529
>
> On Thu, Mar 23, 2023 at 3:57 PM a <a@trwnh.com> wrote:
>
>> > namespacing is overkill for a lot of use cases [...] If plemora and
>> mastodon want to have common terms, in JSON, that's good
>>
>> does this actually work cleanly? my understanding was that JSON-LD
>> processors cannot deterministically handle plain JSON they encounter that
>> isn't defined in @context. based on the JSON-LD playground, a `term`
>> without a mapping will expand to `_:term`; compaction may or may not copy
>> the `term` as-is or otherwise expand it; flattening will simply assign a
>> blank node identifier that replaces the `term` entirely with `b1`; framing
>> will assign `_:b1` to the property name. N-Quads will completely remove any
>> such statements where the predicate is not namespaced.
>>
>> per as2-core, activitystreams documents are defined as compacted against
>> the activitystreams context at minimum, and there is this language
>> regarding undefined terms:
>> https://www.w3.org/TR/activitystreams-core/#jsonld
>>
>> > Implementations may also use additional properties and values not
>> defined in the JSON-LD @context with the understanding that any such
>> properties will likely be unsupported and ignored by consuming
>> implementations that use the standard JSON-LD algorithms.
>>
>> so we can't easily depend on "just" attaching properties as plain JSON.
>> unless we were to define a conformance profile spec that mandated "plain
>> JSON" support, and gave JSON-LD processors extra work to do. (currently,
>> the balance is the other way around; plain JSON parsers need to do extra
>> work to handle things like `Public` vs `as:Public` vs `
>> https://www.w3.org/ns/activitystreams#Public`
>> <https://www.w3.org/ns/activitystreams#Public> being the same thing.
>> generic JSON-LD consumers can handle this case trivially.) we might
>> similarly imagine a conformance profile which mandated "plain JSON" *only*,
>> eliminating support for generic JSON-LD parsers and only supporting
>> "JSON-LD enabled Activity Streams 2.0 implementations" which special-case
>> the media-type `application/activity+json` and inject the normative
>> @context definition if it is missing (which in this case, it very well
>> might be). anyone wishing to use flattened or framed JSON-LD would not be
>> able to interoperate fully until such extension terms were defined.
>>
>