Re: Should the specs be forked and maintained elsewhere?

pá 24. 3. 2023 v 16:59 odesílatel Aaron Gray <aaronngray@gmail.com> napsal:

> On Fri, 24 Mar 2023 at 01:23, Benjamin Goering <ben@bengo.co> wrote:
>
>> from 2018 https://github.com/w3c/ac
>> <https://github.com/w3c/activitystreams/issues/479>
>>
>>>
>>> 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
>>>
>>
> It would be good to have websites for our endeavours paralleling a github
> organization and repos for the websites and standards and code / library
> repos. Ideally these would be .org's rather than .com's though.
>
> There is a https://github.com/swicg with three repositories two empty and
> with virtually nothing in the third but a reference to
> https://www.w3.org/community/swicg/ and no real activity since 2021 when
> the empty repos were created its owned by Aaron Parecki and Dmitri
> Zagidulin
>
> I propose that we collect and produce libraries in all the major languages
> for JSON-LD, ActivityPub, ActivityStreams 2, and extensions, and also for
> RDF, and OWL.
>
> And maybe we have a URI/IRI caching server that can redirect non normative
> URI's to JSON-LD or RDF or OWL descriptor code.
>
>
>>>
>>> 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.
>>>
>>
> This is an excellent idea
>
> I know URI's are URI's. But it would be lovely if on using the HTTP Accept
> header on a GET we could get the turtle or RDF OWL Activity Streams spec,
> rather than having to use a different path, as above.
>
>     GET /ns/activitystreams HTTP/1.1
>     Host: www.w3.org
>     Accept: text/turtle
>
> The main issues with this whole affair though is most people and
> implementations are working on hard hand coded code that only work with
> fixed meta data instances i.e. subsets, supersets, or intersecting protocol
> sets. And not meta descriptive agent instances.
>
> Being able to query a server using WebFinger and
> /.well-known/activitystreams.json for a turtle RDF or OWL spec, to the
> very minimum just the ActivityStreams 2 Standard URL :-
>
>     GET /.well-known/activitystreams.json HTTP/1.1
>     Host: www.example.org <http://www.w3.org/>
>     Accept: application/json
>
> Returning :-
>     {
>         "context": "https://www.w3.org/ns/activitystreams",
>         "version": "2.0",
>         "normative": "true"
>     }
>
> But this should only be offered up by the server or agent *if and only if* it
> supports the whole normative standard, otherwise a subset, superset, or
> intersecting set, OWL turtle spec should be offered up.
>
> This is then just a matter of serving up a static file to be compliant for
> the more versatile to be able to communicate with them.
>
> This is similar to a capabilities model
>
> The problem is people and implementations not adhering directly to the
> full standard, I know you are allowed to implement the standard willy nilly
> in part and add fields too.
>
> This would normalize standards compliance as far as I see possible at this
> stage.
>

We used "content negotiation" in Solid, and unfortunately, it has been a
source of bugs for me. In my opinion, it was a non optimal design decision
that added a lot of complexity.


>
> Regards,
>
> Aaron
>